Was ist der Vorteil, wenn Sie eine composer.json-Datei explizit in mein Plugin aufnehmen, wenn potenzielle Benutzer meines Plugins sie bereits als Paket über WPackagist erhalten können?

TL; DR

Wenn Sie Composer unterstützen möchten, ist das Hinzufügen von a composer.jsonbesser, als WPackagist ein Paket für Sie erstellen zu lassen.

Es gibt mehrere Gründe, niemand ist wirklich wichtig, aber wenn man bedenkt, dass das Erstellen eines composer.jsonnicht viel Aufwand erfordert, lohnt es sich wahrscheinlich.

composer.json Leistungen

Nachfolgend finden Sie eine nicht erschöpfende Liste der Vorteile der Verwendung composer.json.

Entwicklerfreundlich

Wenn Sie ein Paket benötigen, sucht Composer in Repositorys nach diesem bestimmten Paket. Packagist und WPackagist sind 2 Repositories.

Der Unterschied besteht darin, dass Packagist immer von Composer analysiert wird, während WPackagist manuell zum Projekt hinzugefügt werden muss composer.json.

Um ein Plugin für Packagist zu benötigen, benötigen Sie eine einzelne Zeile in composer.json:

"require": {
    "your-name/your-plugin-name":"1.*",
}

Um ein Plugin für WPackagist zu benötigen, müssen Sie auch Repositorys konfigurieren:

"repositories":[
    {
        "type":"composer",
        "url":"http://wpackagist.org"
    }
],
"require": {
    "your-name/your-plugin-name":"1.*",
}

Dies ist auch bei Verwendung der Befehlszeile relevant, siehe

composer create-project your-name/your-plugin-name

VS

composer create-project wpackagist-plugin/your-plugin-name --repository-url=http://wpackagist.org

Performance

Wenn ein Projekt mehr Repositorys enthält, pingt Composer alle an , um Informationen zu Paketen zu erhalten.

Das Hinzufügen des WPackagist-Repositorys verlangsamt die Installation. Bedenken Sie auch, dass alle Server für jede Resonanz ausgefallen sein können. Es passiert viel größeren Unternehmen als dem hinter WPackagist. Jedes hinzugefügte Repository ist also ein zusätzlicher möglicher Fehlerpunkt.

Aufbau

Einer der Vorteile von a composer.jsonist, dass Sie konfigurieren können, wie Composer Ihr Plugin abruft.

Sie können beispielsweise den Paketnamen in der nameEigenschaft konfigurieren , anstatt WPackagist den Paketnamen für Sie erstellen zu lassen.

Darüber hinaus gibt es eine Menge Konfigurationsmöglichkeiten composer.json, nur einige Beispiele:

• Mit dieser branch-aliasEinstellung können Sie die Kompatibilität der Entwicklungsversion des Plugins verbessern
• Selbst wenn Sie keine Abhängigkeiten haben, können Sie die requireEinstellung verwenden, um eine minimale PHP-Version festzulegen.
• Mit dieser conflictEinstellung können Sie explizit über widersprüchliche Pakete informieren ...

und so weiter.

Eigentümerbewusstsein

Wenn Sie ein Plugin von WPackagist benötigen, ist der "Hersteller" -Teil des Paketnamens immer wpackagist-plugin.

Die Leute benötigen also ein Plugin wie:

"require": {
    "wpackagist-plugin/your-plugin-name":"1.*",
}

Wenn Sie das Plugin auf packagist setzen, können Sie Ihr eigenes Herstellerpräfix verwenden, und ich denke, es ist besser für das Marketing:

"require": {
    "your-name/your-plugin-name":"1.*",
}

Autoload

Composer bietet Autoload für Pakete. Wenn Sie sich für Composer entscheiden, können Sie davon profitieren. Wenn Sie jedoch bedenken, dass Sie Ihr Plugin an ein offizielles Repo senden, müssen Sie berücksichtigen, dass die Mehrheit Ihrer Benutzer Ihr Plugin wahrscheinlich ohne Composer installieren wird. Es bedeutet, dass Sie Möglichkeiten haben:

• Versenden Sie den Ordner "Vendor" (der das Autoload enthält) in Ihren Plugin-Ordner im offiziellen Repo
• Verwenden Sie einen benutzerdefinierten Autoloader oder einen manuellen Lademechanismus, falls das Plugin ohne Composer verwendet wird.

Die zweite Möglichkeit wird nur erwähnt, weil Ihr Plugin keine von Composer verwalteten Abhängigkeiten aufweist. Andernfalls ist der Versandanbieterordner die einzige Möglichkeit, Ihr Plugin ohne Composer zum Laufen zu bringen, ist jedoch nicht problemlos: Wenn verschiedene Plugins mit eingebettetem Anbieterordner installiert sind, gibt es diese Die Möglichkeit von Versionskonflikten, wenn verschiedene Plugins unterschiedliche Versionen desselben Pakets liefern.

Explizite Composer-Unterstützung

Durch das Hinzufügen composer.jsonmachen Sie die Leute darauf aufmerksam, dass Sie Composer ausdrücklich unterstützen. Wenn ich zum Beispiel nach einem Plugin suche, composer.jsonist es ein großes Plus für mich, ein Plugin im Plugin-Ordner zu finden , da ich normalerweise keine Plugins verwende, die das nicht tun.

Darüber hinaus gibt es Tools, die auf Plugins abzielen, die Composer explizit unterstützen.

Zum Beispiel habe ich ein Skript, das automatische Updates für Plugins / Themes mit einem verhindert composer.json.

Die composer.jsonDatei enthält normalerweise zusätzliche Informationen, die in der readme.txtDatei nicht verfügbar sind . Es könnte also einfach als Readme- Datei für die Abhängigkeiten Ihres Plugins dienen.

Da sich Composer in der Toolbox vieler Entwickler befindet, kann es ihnen helfen, besser zu verstehen, wie Ihr Plugin zusammengeschraubt ist.

Für z. B. verlassene .org-Plugins wäre es praktisch, diese Datei für jemanden verfügbar zu haben, der sie teilen, aktualisieren und erweitern möchte.

Wenn wir unser Plugin auf packagist.org registrieren wollen, brauchen wir es natürlich.