Qual è la differenza tra le sezioni require e require-dev in composer.json?

99

Sto iniziando a usare il compositore, ne so così poco e ho una piccola esperienza con lo sviluppo di applicazioni web.

Ho appena esaminato Nettuts + Tutorial , quindi ho una domanda di base sul compositore.

{
  "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. Qualunque cosa appaia in "require-dev"parte, verrà scaricata e installata solo con composer install --dev?
  2. Ho letto parte della documentazione del compositore ma ancora non capisco qual è il motivo per cui "require-dev"partecipiamo? È perché vogliamo ottenere una versione specifica del pacchetto piuttosto che ottenere sempre l'ultima versione stabile?
composer-php 
— Artigiano
fonte
— sampablokuper

Risposte:

115

Ambienti diversi

In genere, il software verrà eseguito in ambienti diversi:

  • development
  • testing
  • staging
  • production

Dipendenze diverse in ambienti diversi

Le dipendenze dichiarate nella requiresezione di composer.jsonsono in genere dipendenze richieste per eseguire un'applicazione o un pacchetto in

  • staging
  • production

ambienti, mentre le dipendenze dichiarate nella require-devsezione sono tipicamente dipendenze richieste in

  • developing
  • testing

ambienti.

Ad esempio, oltre ai pacchetti utilizzati per eseguire effettivamente un'applicazione, potrebbero essere necessari pacchetti per lo sviluppo del software, come:

  • friendsofphp/php-cs-fixer (per rilevare e risolvere problemi di stile di codifica)
  • squizlabs/php_codesniffer (per rilevare e risolvere problemi di stile di codifica)
  • phpunit/phpunit (per guidare lo sviluppo utilizzando i test)
  • eccetera.

Distribuzione

Ora, in developmente testingambienti, in genere corri

$ composer install

per installare sia productione le developmentdipendenze.

Tuttavia, in staginge productionambienti, si desidera installare solo le dipendenze necessarie per l'esecuzione dell'applicazione e, come parte del processo di distribuzione, si eseguiranno in genere

$ composer install --no-dev

per installare solo le productiondipendenze.

Semantica

In altre parole, le sezioni

  • require
  • require-dev

indicare a composerquali pacchetti devono essere installati durante l'esecuzione

$ composer install

o

$ composer install --no-dev

Questo è tutto.

Nota Le dipendenze di sviluppo dei pacchetti da cui dipende l'applicazione o il pacchetto non verranno mai installate

Per riferimento, vedere:

— localheinz
fonte
Ho capito bene che non importa affatto se "distribuisco" caricando l'intera vendorcartella tramite FTP?
— pilat
2
@pilat Puoi, ma assicurati di installare con —no-dev. Inoltre, l'FTP sarà probabilmente piuttosto lento.
— localheinz
Che ne dici delle dipendenze di cui hai bisogno solo per creare la tua applicazione? Quindi, in una pipeline di compilazione e distribuzione, vorrei installarli per la creazione e quindi rimuoverli di nuovo prima della distribuzione. Ad esempio per la minificazione, o trasformare LESS / SASS in css. Come lo faresti?
— Richard Kiefer
1
@RichardKiefer Alcune persone usano phar.io , altri registrano PHAR, altri ancora usano immagini Docker, e anche alcune persone usano un separato composer.json- vedi ad esempio github.com/FriendsOfPHP/PHP-CS-Fixer/tree/2.16/dev-tools .
— localheinz
Quindi invieresti solo il composer.json e lo bloccheresti nel tuo repo? Non ha più senso eseguire il commit di tutto e per il deploy basta estrarre il ramo master dalla produzione usando git?
— mbomb007
61

  1. Secondo il manuale del compositore :

    require-dev (solo root)

    Elenca i pacchetti richiesti per lo sviluppo di questo pacchetto, o l'esecuzione di test, ecc. I requisiti dev del pacchetto root sono installati per impostazione predefinita. Entrambi installo updatesupportano l' --no-devopzione che impedisce l'installazione delle dipendenze dev.

    Quindi l'esecuzione composer installscaricherà anche le dipendenze di sviluppo.

  2. Il motivo è in realtà abbastanza semplice. Quando contribuisci a una libreria specifica, potresti voler eseguire suite di test o altri strumenti di sviluppo (ad esempio symfony). Ma se installi questa libreria in un progetto, quelle dipendenze di sviluppo potrebbero non essere richieste: non tutti i progetti richiedono un test runner.

— Florent
fonte
19

Dal sito del compositore (è abbastanza chiaro)

richiedono #

Elenca i pacchetti richiesti da questo pacchetto. Il pacchetto non verrà installato a meno che tali requisiti non vengano soddisfatti.

require-dev (solo root) #

Elenca i pacchetti richiesti per lo sviluppo di questo pacchetto, o l'esecuzione di test, ecc. I requisiti di sviluppo del pacchetto root sono installati per impostazione predefinita. Sia l'installazione che l'aggiornamento supportano l'opzione --no-dev che impedisce l'installazione delle dipendenze dev.

Usando require-dev in Composer puoi dichiarare le dipendenze necessarie per lo sviluppo / test del progetto ma non necessarie in produzione. Quando carichi il progetto sul tuo server di produzione (usando git) la require-devparte verrebbe ignorata.

Controlla anche questa risposta pubblicata dall'autore e anche questo post .

— L'Alfa
fonte
3
Per favore, spiegami perché "way / generators": "dev-master" è nella sezione "require" ?, non ne avrei più bisogno nella produzione.
— Artigiano
1
Questa è un'ipotesi totale, ma l'unica cosa a cui riesco a pensare è che, poiché il modo / generators viene aggiunto come fornitore di servizi, se manca nell'ambiente di produzione, Laravel non funzionerà.
— Daniel Hollands,
2
La parte I requisiti dev del pacchetto root sono installati di default afferma chiaramente che le dipendenze da require-dev sono installate, anche sul server di produzione.
— Gemmu
3
L'idea è di utilizzare il flag --no-dev in produzione.
— John Pancoast
2

sezione require Questa sezione contiene i pacchetti / dipendenze che sono candidati migliori per essere installati / richiesti nell'ambiente di produzione.

Sezione require-dev: questa sezione contiene i pacchetti / dipendenze che possono essere usati dallo sviluppatore per testare il suo codice (o per sperimentare sulla sua macchina locale e lei non vuole che questi pacchetti siano installati nell'ambiente di produzione).

— MKJ
fonte
1

La regola generale è che vuoi pacchetti dalla sezione require-dev solo negli ambienti di sviluppo (dev), ad esempio l'ambiente locale.

I pacchetti nella sezione require-dev sono pacchetti che ti aiutano a eseguire il debug di app, eseguire test, ecc.

Nell'ambiente di staging e di produzione probabilmente vuoi solo i pacchetti dalla sezione require .

Ma comunque puoi eseguire composer install --no-dev e composer update --no-dev su qualsiasi ambiente, il comando installerà solo i pacchetti dalla sezione richiesta non da require-dev , ma probabilmente vorrai eseguirlo solo in fase di staging e produzione ambienti non in locale.

Teoricamente puoi mettere tutti i pacchetti nella sezione require e non accadrà nulla, ma non vuoi sviluppare pacchetti nell'ambiente di produzione per i seguenti motivi:

  1. velocità
  2. potenziale di esporre alcune informazioni di debug
  3. eccetera

Alcuni buoni candidati per require-dev sono:

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

puoi vedere cosa stanno facendo i pacchetti sopra e vedrai perché non ne hai bisogno in produzione.

Vedi di più qui: https://getcomposer.org/doc/04-schema.md

— fico7489
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.