Was ist der Unterschied zwischen den Abschnitten require und require-dev in composer.json?

97

Ich fange an, Composer zu verwenden, ich weiß so wenig darüber und habe ein wenig Erfahrung mit der Entwicklung von Webanwendungen.

Ich gehe einfach durch Nettuts + Tutorial , also habe ich grundlegende Fragen zum Komponisten.

{
  "require": {
    "laravel/framework": "4.0.*",
    "way/generators": "dev-master",
    "twitter/bootstrap": "dev-master",
    "conarwelsh/mustache-l4": "dev-master"
  },
  "require-dev": {
    "phpunit/phpunit": "3.7.*",
    "mockery/mockery": "0.7.*"
  },
  "autoload": {
    "classmap": [
      "app/commands",
      "app/controllers",
      "app/models",
      "app/database/migrations",
      "app/database/seeds",
      "app/tests/TestCase.php"
    ]
  },
  "scripts": {
    "post-update-cmd": "php artisan optimize"
  },
  "minimum-stability": "dev"
}
  1. Was auch immer teilweise erscheint "require-dev", wird nur mit heruntergeladen und installiert composer install --dev?
  2. Ich habe einige Dokumentationen des Komponisten gelesen, verstehe aber immer noch nicht, warum wir einen "require-dev"Teil davon haben. Liegt es daran, dass wir eine bestimmte Version des Pakets erhalten möchten, anstatt immer die neueste stabile Version zu erhalten?
composer-php Handwerker
quelle
Siehe auch
sampablokuper

Antworten:

111

Unterschiedliche Umgebungen

In der Regel wird Software in verschiedenen Umgebungen ausgeführt:

  • development
  • testing
  • staging
  • production

Unterschiedliche Abhängigkeiten in unterschiedlichen Umgebungen

Die Abhängigkeiten, die im requireAbschnitt von deklariert werden, composer.jsonsind normalerweise Abhängigkeiten, die zum Ausführen einer Anwendung oder eines Pakets in erforderlich sind

  • staging
  • production

Umgebungen, während die im require-devAbschnitt deklarierten Abhängigkeiten normalerweise Abhängigkeiten sind, die in erforderlich sind

  • developing
  • testing

Umgebungen.

Zusätzlich zu den Paketen, die zum tatsächlichen Ausführen einer Anwendung verwendet werden, werden möglicherweise Pakete für die Entwicklung der Software benötigt, z.

  • friendsofphp/php-cs-fixer (um Probleme mit dem Codierungsstil zu erkennen und zu beheben)
  • squizlabs/php_codesniffer (um Probleme mit dem Codierungsstil zu erkennen und zu beheben)
  • phpunit/phpunit (um die Entwicklung mit Tests voranzutreiben)
  • etc.

Einsatz

In developmentund in testingUmgebungen werden Sie normalerweise ausgeführt

$ composer install

um beide productionund developmentAbhängigkeiten zu installieren .

Doch in stagingund productionUmgebungen, wollen Sie nur Abhängigkeiten installieren , die für die Ausführung der Anwendung erforderlich sind, und als Teil des Bereitstellungsprozesses, würden Sie in der Regel laufen

$ composer install --no-dev

um nur productionAbhängigkeiten zu installieren .

Semantik

Mit anderen Worten, die Abschnitte

  • require
  • require-dev

Geben Sie an, auf composerwelche Pakete installiert werden soll, wenn Sie ausgeführt werden

$ composer install

oder

$ composer install --no-dev

Das ist alles.

Hinweis Entwicklungsabhängigkeiten von Paketen, von denen Ihre Anwendung oder Ihr Paket abhängt, werden niemals installiert

Als Referenz siehe:

localheinz
quelle
Verstehe ich richtig, dass es überhaupt keine Rolle spielt, ob ich durch Hochladen des gesamten vendorOrdners über FTP "bereitstelle" ?
Pilat
2
@pilat Sie können, aber stellen Sie sicher, mit zu installieren —no-dev. Auch FTP wird wahrscheinlich ziemlich langsam sein.
localheinz
Wie wäre es mit Abhängigkeiten, die Sie nur zum Erstellen Ihrer Anwendung benötigen? In einer Build- und Deployment-Pipeline möchte ich sie zum Erstellen installieren und dann vor dem Bereitstellen wieder entfernen. ZB zur Minimierung oder zur Umwandlung von LESS / SASS in CSS. Wie würdest du das machen?
Richard Kiefer
1
@RichardKiefer Einige Leute verwenden phar.io , andere checken PHARs ein, andere verwenden Docker-Images und einige verwenden ein separates composer.json- siehe zum Beispiel github.com/FriendsOfPHP/PHP-CS-Fixer/tree/2.16/dev-tools .
localheinz
Würden Sie also nur die Datei composer.json festlegen und Ihr Repo sperren? Ist es nicht sinnvoller, alles festzuschreiben und für die Bereitstellung einfach den Hauptzweig mit git aus der Produktion zu ziehen?
mbomb007
61

  1. Nach dem Handbuch des Komponisten :

    require-dev (nur root)

    Listet Pakete auf, die zum Entwickeln dieses Pakets oder zum Ausführen von Tests usw. erforderlich sind. Die Entwicklungsanforderungen des Root-Pakets sind standardmäßig installiert. Beide installoder updateunterstützen die --no-devOption, die verhindert, dass Entwicklungsabhängigkeiten installiert werden.

    Beim Ausführen composer installwerden also auch die Entwicklungsabhängigkeiten heruntergeladen.

  2. Der Grund ist eigentlich ganz einfach. Wenn Sie zu einer bestimmten Bibliothek beitragen, möchten Sie möglicherweise Testsuiten oder andere Entwicklungstools (z. B. Symfony) ausführen. Wenn Sie diese Bibliothek jedoch in einem Projekt installieren, sind diese Entwicklungsabhängigkeiten möglicherweise nicht erforderlich: Nicht für jedes Projekt ist ein Testläufer erforderlich.

Florent
quelle
19

Von der Komponisten-Site (es ist klar genug)

benötigen#

Listet die für dieses Paket erforderlichen Pakete auf. Das Paket wird erst installiert, wenn diese Anforderungen erfüllt werden können.

require-dev (nur root) #

Listet Pakete auf, die zum Entwickeln dieses Pakets oder zum Ausführen von Tests usw. erforderlich sind. Die Entwicklungsanforderungen des Root-Pakets sind standardmäßig installiert. Sowohl die Installation als auch die Aktualisierung unterstützen die Option --no-dev, die verhindert, dass Entwicklungsabhängigkeiten installiert werden.

Mit require-dev in Composer können Sie die Abhängigkeiten deklarieren, die Sie für die Entwicklung / das Testen des Projekts benötigen, aber in der Produktion nicht benötigen. Wenn Sie das Projekt auf Ihren Produktionsserver (mit git) hochladen, wird der require-devTeil ignoriert.

Überprüfen Sie auch diese Antwort des Autors und diesen Beitrag .

Das Alpha
quelle
3
Bitte erklären Sie mir, warum "way / generators": "dev-master" im Abschnitt "require" steht. Ich würde es in der Produktion nicht mehr brauchen.
Artisan
1
Dies ist eine totale Vermutung, aber das einzige, was ich mir vorstellen kann, ist, dass Laravel nicht funktioniert, da Way / Generators als Dienstleister hinzugefügt werden, wenn es in der Produktionsumgebung fehlt.
Daniel Hollands
2
Der Teil Die Entwicklungsanforderungen des Root-Pakets sind standardmäßig installiert und geben eindeutig an, dass die Abhängigkeiten von require-dev auch auf dem Produktionsserver installiert sind.
Gemmu
3
Die Idee ist, dass Sie das Flag --no-dev für die Produktion verwenden.
John Pancoast
2

Erforderlicher Abschnitt Dieser Abschnitt enthält die Pakete / Abhängigkeiten, die bessere Kandidaten für die Installation / Anforderung in der Produktionsumgebung sind.

require-dev-Abschnitt: Dieser Abschnitt enthält die Pakete / Abhängigkeiten, mit denen der Entwickler seinen Code testen kann (oder um auf seinem lokalen Computer zu experimentieren, und er möchte nicht, dass diese Pakete in der Produktionsumgebung installiert werden).

MKJ
quelle
1

Die allgemeine Regel lautet, dass Sie Pakete aus dem Abschnitt " require-dev " nur in Entwicklungsumgebungen (dev) wünschen , z. B. in einer lokalen Umgebung.

Pakete im Abschnitt require-dev sind Pakete, mit denen Sie Apps debuggen, Tests ausführen usw. können.

In der Staging- und Produktionsumgebung möchten Sie wahrscheinlich nur Pakete aus dem erforderlichen Bereich.

Sie können die Composer-Installation --no-dev und das Composer-Update --no-dev jedoch in jeder Umgebung ausführen. Der Befehl installiert nur Pakete aus dem erforderlichen Abschnitt, nicht aus require-dev . Wahrscheinlich möchten Sie dies jedoch nur beim Staging und bei der Produktion ausführen Umgebungen nicht lokal.

Theoretisch können Sie alle Pakete in den erforderlichen Bereich stellen, und es wird nichts passieren, aber Sie möchten aus folgenden Gründen keine Pakete in der Produktionsumgebung entwickeln:

  1. Geschwindigkeit
  2. Potenzial, einige Debug-Informationen verfügbar zu machen
  3. etc

Einige gute Kandidaten für require-dev sind:

"filp/whoops": "^2.0",
"fzaninotto/faker": "^1.4",
"mockery/mockery": "^1.0",
"nunomaduro/collision": "^2.0",
"phpunit/phpunit": "^7.0"

Sie können sehen, was die oben genannten Pakete tun, und Sie werden sehen, warum Sie sie für die Produktion nicht benötigen.

Weitere Informationen finden Sie hier: https://getcomposer.org/doc/04-schema.md

fico7489
quelle