Warum sollte ich eine composer.json Datei mit meinem Plugin einbinden?

Was ist der Vorteil, wenn ich eine composer.json-Datei explizit in mein Plugin einfüge, wenn potenzielle Nutzer meines Plugins sie bereits als Paket über WPackagist erhalten?

Solutions Collecting From Web of "Warum sollte ich eine composer.json Datei mit meinem Plugin einbinden?"

TL; DR

Wenn Sie Composer unterstützen möchten, ist das Hinzufügen einer composer.json besser, als nur WPackagist ein Paket für Sie erstellen.

Es gibt mehrere Gründe, niemand ist wirklich wichtig, aber wenn man bedenkt, dass ein composer.json keinen großen Aufwand erfordert, lohnt es sich wahrscheinlich.

composer.json Vorteile

Im Folgenden finden Sie eine nicht erschöpfende Liste der Vorteile von composer.json .

Entwicklerfreundlich

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

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

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

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

Um ein Plugin auf WPackagist zu benötigen, müssen Sie auch Repositories konfigurieren:

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

Dies ist auch relevant, wenn Sie die Befehlszeile verwenden, 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 Repositories enthält, pingt der Composer alle , um Informationen zu Paketen zu finden.

Das Hinzufügen des WPackagist-Repositorys verlangsamt die Installation. Bedenken Sie auch, dass alle Server für jeden reson ausfallen können. Es passiert viel größeren Unternehmen als dem, das hinter WPackagist steht, also ist jedes Repository, das Sie hinzufügen, eine weitere mögliche Fehlerquelle.

Aufbau

Einer der Vorteile von composer.json besteht darin, dass Sie festlegen können, wie Composer Ihr Plug-in abruft.

Sie können zum Beispiel den Paketnamen in der Eigenschaft name konfigurieren, anstatt WPackagist den Paketnamen für Sie erstellen zu lassen.

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

  • Sie können die Einstellung für Zweigalias verwenden, um die Kompatibilität der Entwicklungsversion des Plugins zu verbessern
  • Auch wenn Sie keine Abhängigkeiten haben, können Sie mit der Einstellung require eine PHP-Mindestversion festlegen,
  • Mit der conflict Sie explizit über widersprüchliche Pakete informieren …

und so weiter.

Eigentumsbewusstsein

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

So werden Leute benötigen Sie Plugin wie:

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

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

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

Automatisches Laden

Composer bietet Autoload für Pakete. Wenn Sie sich für die Verwendung von Composer entscheiden, können Sie davon profitieren. In Anbetracht dessen, dass Sie Ihr Plugin an offizielle Repo-Produkte verschicken, müssen Sie berücksichtigen, dass der Großteil Ihrer Benutzer Ihr Plugin wahrscheinlich ohne Composer installieren wird. Es bedeutet, dass Sie Möglichkeiten haben:

  • Versenden Sie den “Vendor” -Ordner (der das Autoload enthält) ins Innere Ihres Plugin-Ordners 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 Abhängigkeiten vom Composer hat, ansonsten ist der Ordner Lieferantenversorger die einzige Möglichkeit, Ihr Plugin ohne Composer arbeiten zu lassen, aber es ist nicht problemfrei: wenn verschiedene Plugins mit eingebettetem Lieferantenordner installiert sind die Möglichkeit von Versionskonflikten, wenn verschiedene Plugins unterschiedliche Versionen des gleichen Pakets versenden.

Unterstützung für explizite Composer

Wenn Sie composer.json hinzufügen, werden Sie wissen, dass Sie Composer explizit unterstützen. Wenn ich zum Beispiel nach einem Plugin suche, ist es ein großes Plus für mich, ein composer.json im Plugin-Ordner zu finden, da ich dazu tendiere, keine Plugins zu verwenden, die das nicht tun.

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

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

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

Da Composer in der Toolbox vieler Entwickler ist, könnte es ihnen helfen, besser zu verstehen, wie Ihr Plugin verschraubt ist.

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

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