Quelle est la différence entre les sections require et require-dev dans composer.json?

99

Je commence à utiliser composer, j'en connais si peu et j'ai une petite expérience du développement d'applications Web.

Je viens de parcourir Nettuts + Tutorial , donc j'ai une question de base sur le compositeur.

{
  "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. Tout ce qui apparaît en "require-dev"partie ne sera téléchargé et installé qu'avec composer install --dev?
  2. J'ai lu une partie de la documentation du compositeur mais je ne comprends toujours pas quelle est la raison pour laquelle nous avons une "require-dev"partie? Est-ce parce que nous voulons obtenir une version spécifique du paquet plutôt que toujours la dernière version stable?
composer-php Artisan
la source
En relation: stackoverflow.com/q/16679589/82216
sampablokuper

Réponses:

115

Différents environnements

En règle générale, les logiciels s'exécutent dans différents environnements:

  • development
  • testing
  • staging
  • production

Différentes dépendances dans différents environnements

Les dépendances qui sont déclarées dans la requiresection de composer.jsonsont généralement des dépendances qui sont requises pour exécuter une application ou un package dans

  • staging
  • production

environnements, alors que les dépendances déclarées dans la require-devsection sont généralement des dépendances qui sont requises dans

  • developing
  • testing

environnements.

Par exemple, en plus des packages utilisés pour exécuter une application, des packages peuvent être nécessaires pour développer le logiciel, tels que:

  • friendsofphp/php-cs-fixer (pour détecter et résoudre les problèmes de style de codage)
  • squizlabs/php_codesniffer (pour détecter et résoudre les problèmes de style de codage)
  • phpunit/phpunit (pour piloter le développement à l'aide de tests)
  • etc.

Déploiement

Maintenant, dans les environnements developmentet testing, vous exécutez généralement

$ composer install

pour installer les deux productionet les developmentdépendances.

Cependant, dans les environnements staginget production, vous ne souhaitez installer que les dépendances nécessaires à l'exécution de l'application, et dans le cadre du processus de déploiement, vous exécutez généralement

$ composer install --no-dev

pour installer uniquement les productiondépendances.

Sémantique

En d'autres termes, les sections

  • require
  • require-dev

indiquer dans composerquels packages doivent être installés lors de l'exécution

$ composer install

ou

$ composer install --no-dev

C'est tout.

Remarque Les dépendances de développement des packages dont dépend votre application ou package ne seront jamais installées

Pour référence, voir:

localheinz
la source
Dois-je bien comprendre, que ce n'est pas du tout important si je "déploie" en téléchargeant le vendordossier entier via FTP?
pilat
2
@pilat Vous pouvez, mais assurez-vous d'installer avec —no-dev. De plus, FTP sera probablement assez lent.
localheinz
Qu'en est-il des dépendances dont vous avez besoin pour créer votre application uniquement? Donc, dans un pipeline de construction et de déploiement, je voudrais les installer pour la construction, puis les supprimer à nouveau avant le déploiement. Par exemple pour la minification, ou pour transformer LESS / SASS en css. Comment feriez-vous cela?
Richard Kiefer
1
@RichardKiefer Certaines personnes utilisent phar.io , d'autres enregistrent des PHAR, d'autres encore utilisent des images Docker, et certaines personnes en utilisent également une autre composer.json- voir par exemple github.com/FriendsOfPHP/PHP-CS-Fixer/tree/2.16/dev-tools .
localheinz
Voulez-vous seulement valider le composer.json et verrouiller votre dépôt? N'est-il pas plus logique de tout valider et, pour le déploiement, d'extraire simplement la branche master de la production à l'aide de git?
mbomb007 le
61

  1. Selon le manuel du compositeur :

    require-dev (root uniquement)

    Répertorie les packages requis pour développer ce package, ou exécuter des tests, etc. Les exigences de développement du package racine sont installées par défaut. Les deux installou updateprennent en charge l' --no-devoption qui empêche l'installation des dépendances dev.

    L'exécution composer installtéléchargera donc également les dépendances de développement.

  2. La raison est en fait assez simple. Lorsque vous contribuez à une bibliothèque spécifique, vous voudrez peut-être exécuter des suites de tests ou d'autres outils de développement (par exemple symfony). Mais si vous installez cette bibliothèque dans un projet, ces dépendances de développement peuvent ne pas être requises: tous les projets ne nécessitent pas un exécuteur de test.

Florent
la source
19

Depuis le site du compositeur (c'est assez clair)

exiger#

Répertorie les packages requis par ce package. Le package ne sera installé que si ces exigences peuvent être satisfaites.

require-dev (root uniquement) #

Répertorie les packages requis pour développer ce package, ou exécuter des tests, etc. Les exigences de développement du package racine sont installées par défaut. L'installation ou la mise à jour prennent en charge l'option --no-dev qui empêche l'installation des dépendances dev.

En utilisant require-dev dans Composer, vous pouvez déclarer les dépendances dont vous avez besoin pour le développement / test du projet mais dont vous n'avez pas besoin en production. Lorsque vous téléchargez le projet sur votre serveur de production (à l'aide de git), la require-devpartie est ignorée.

Vérifiez également cette réponse publiée par l' auteur et cet article .

L'Alpha
la source
3
Veuillez m'expliquer pourquoi "way / generators": "dev-master" est dans la section "require"?, Je n'en aurais plus besoin dans la production.
Artisan
1
C'est une supposition totale, mais la seule chose à laquelle je peux penser est que parce que la façon dont / generators est ajoutée en tant que fournisseur de services, si elle manque dans l'environnement de production, Laravel ne fonctionnera pas.
Daniel Hollands
2
La partie Les exigences dev du paquet racine sont installées par défaut indique clairement que les dépendances de require-dev sont installées, même sur le serveur de production.
Gemmu
3
L'idée est que vous utiliseriez l'indicateur --no-dev en production.
John Pancoast
2

section require Cette section contient les packages / dépendances qui sont les meilleurs candidats pour être installés / requis dans l'environnement de production.

Section require-dev: Cette section contient les packages / dépendances qui peuvent être utilisés par le développeur pour tester son code (ou pour expérimenter sur sa machine locale et elle ne souhaite pas que ces packages soient installés sur l'environnement de production).

MKJ
la source
1

La règle générale est que vous voulez des packages de la section require-dev uniquement dans les environnements de développement (dev), par exemple l'environnement local.

Les packages de la section require-dev sont des packages qui vous aident à déboguer l'application, à exécuter des tests, etc.

Dans l' environnement de préparation et de production , vous ne voulez probablement que des packages de la section require .

Mais de toute façon, vous pouvez exécuter composer install --no-dev et composer update --no-dev sur n'importe quel environnement, la commande installera uniquement les packages de la section requise et non de require-dev , mais vous souhaitez probablement l'exécuter uniquement lors de la préparation et de la production environnements pas sur local.

Théoriquement, vous pouvez placer tous les packages dans la section require et rien ne se passera, mais vous ne voulez pas développer de packages dans un environnement de production pour les raisons suivantes:

  1. la vitesse
  2. potentiel d'exposer des informations de débogage
  3. etc

Quelques bons candidats pour require-dev sont:

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

vous pouvez voir ce que font les packages ci-dessus et vous verrez pourquoi vous n'en avez pas besoin en production.

Voir plus ici: https://getcomposer.org/doc/04-schema.md

fico7489
la source