¿Cuál es la diferencia entre las secciones require y require-dev en composer.json?

99

Estoy empezando a usar Composer, sé muy poco sobre él y tengo un poco de experiencia con el desarrollo de aplicaciones web.

Acabo de revisar el tutorial de Nettuts + , así que tengo una pregunta básica sobre el compositor.

{
  "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. Lo que aparezca en "require-dev"parte, solo se descargará e instalará con composer install --dev?
  2. Leí parte de la documentación del compositor pero todavía no entiendo cuál es la razón por la que tenemos "require-dev"parte. ¿Es porque queremos obtener una versión específica del paquete en lugar de obtener siempre la última versión estable?
composer-php 
— Artesano
fuente
— sampablokuper

Respuestas:

115

Diferentes ambientes

Normalmente, el software se ejecutará en diferentes entornos:

  • development
  • testing
  • staging
  • production

Diferentes dependencias en diferentes entornos

Las dependencias que se declaran en la requiresección de composer.jsonson típicamente dependencias que se requieren para ejecutar una aplicación o un paquete en

  • staging
  • production

entornos, mientras que las dependencias declaradas en la require-devsección suelen ser dependencias que se requieren en

  • developing
  • testing

Ambientes.

Por ejemplo, además de los paquetes que se utilizan para ejecutar realmente una aplicación, es posible que se necesiten paquetes para desarrollar el software, como:

  • friendsofphp/php-cs-fixer (para detectar y solucionar problemas de estilo de codificación)
  • squizlabs/php_codesniffer (para detectar y solucionar problemas de estilo de codificación)
  • phpunit/phpunit (impulsar el desarrollo mediante pruebas)
  • etc.

Despliegue

Ahora, en entornos developmenty testing, normalmente ejecutaría

$ composer install

para instalar tanto productiony developmentdependencias.

Sin embargo, en entornos stagingy production, solo desea instalar las dependencias que son necesarias para ejecutar la aplicación y, como parte del proceso de implementación, normalmente ejecutará

$ composer install --no-dev

para instalar solo productiondependencias.

Semántica

En otras palabras, las secciones

  • require
  • require-dev

indicar a composerqué paquetes deben instalarse cuando ejecuta

$ composer install

o

$ composer install --no-dev

Eso es todo.

Nota Las dependencias de desarrollo de los paquetes de los que depende su aplicación o paquete nunca se instalarán

Para referencia, consulte:

— localheinz
fuente
¿Entiendo correctamente que no importa en absoluto si "implemento" cargando toda la vendorcarpeta a través de FTP?
— Pilat
2
@pilat Puede, pero asegúrese de instalar con —no-dev. Además, FTP probablemente será bastante lento.
— localheinz
¿Qué hay de las dependencias que necesita para construir su aplicación, solo? Por lo tanto, en una canalización de compilación e implementación, me gustaría instalarlos para compilar y luego eliminarlos nuevamente antes de implementarlos. Por ejemplo, para la minificación o convertir LESS / SASS en css. ¿Cómo lo harías tú?
— Richard Kiefer
1
@RichardKiefer Algunas personas usan phar.io , otras revisan PHAR, otras usan imágenes de Docker, y también algunas personas usan una imagen separada composer.json- vea, por ejemplo, github.com/FriendsOfPHP/PHP-CS-Fixer/tree/2.16/dev-tools .
— localheinz
Entonces, ¿solo confirmaría composer.json y bloquearía su repositorio? ¿No tiene más sentido comprometer todo y, para la implementación, simplemente extraer la rama maestra de la producción usando git?
— mbomb007
61

  1. Según el manual del compositor :

    require-dev (solo root)

    Enumera los paquetes necesarios para desarrollar este paquete o ejecutar pruebas, etc. Los requisitos de desarrollo del paquete raíz se instalan de forma predeterminada. Ambos installo updateadmiten la --no-devopción que evita que se instalen las dependencias de desarrollo.

    Por lo tanto, ejecutar composer installtambién descargará las dependencias de desarrollo.

  2. La razón es bastante simple. Al contribuir a una biblioteca específica, es posible que desee ejecutar conjuntos de pruebas u otras herramientas de desarrollo (por ejemplo, Symfony). Pero si instala esta biblioteca en un proyecto, es posible que esas dependencias de desarrollo no sean necesarias: no todos los proyectos requieren un ejecutor de pruebas.

— Florent
fuente
19

Desde el sitio del compositor (es lo suficientemente claro)

exigir#

Enumera los paquetes requeridos por este paquete. El paquete no se instalará a menos que se cumplan esos requisitos.

require-dev (solo root) #

Enumera los paquetes necesarios para desarrollar este paquete o ejecutar pruebas, etc. Los requisitos de desarrollo del paquete raíz se instalan de forma predeterminada. Tanto la instalación como la actualización admiten la opción --no-dev que evita que se instalen las dependencias de desarrollo.

Al usar require-dev en Composer, puede declarar las dependencias que necesita para desarrollar / probar el proyecto pero que no necesita en producción. Cuando cargue el proyecto en su servidor de producción (usando git) require-dev, se ignorará una parte.

También verifique esta respuesta publicada por el autor y esta publicación también.

— El alfa
fuente
3
Por favor, explíqueme por qué "way / generators": "dev-master" está en la sección "require" ?, ya no lo necesitaría en la producción.
— Artesano
1
Esta es una suposición total, pero lo único en lo que puedo pensar es que debido a que way / generators se agrega como proveedor de servicios, si falta en el entorno de producción, Laravel no funcionará.
— Daniel Hollands
2
La parte Los requisitos de desarrollo del paquete raíz se instalan de forma predeterminada y establece claramente que las dependencias de require-dev están instaladas, incluso en el servidor de producción.
— Gemmu
3
La idea es que usarías la marca --no-dev en producción.
— John Pancoast
2

sección require Esta sección contiene los paquetes / dependencias que son mejores candidatos para ser instalados / requeridos en el entorno de producción.

Sección require-dev: esta sección contiene los paquetes / dependencias que el desarrollador puede usar para probar su código (o para experimentar en su máquina local y no quiere que estos paquetes se instalen en el entorno de producción).

— MKJ
fuente
1

La regla general es que desea paquetes de la sección require-dev solo en entornos de desarrollo (dev), por ejemplo, un entorno local.

Los paquetes en la sección require-dev son paquetes que lo ayudan a depurar la aplicación, ejecutar pruebas, etc.

En el entorno de ensayo y producción , probablemente solo desee paquetes de la sección require .

Pero de todos modos, puede ejecutar composer install --no-dev y composer update --no-dev en cualquier entorno, el comando instalará solo los paquetes de la sección requerida , no de require-dev , pero probablemente desee ejecutar esto solo en la etapa de prueba y producción entornos no locales.

Teóricamente, puede colocar todos los paquetes en la sección require y no pasará nada, pero no desea desarrollar paquetes en el entorno de producción por las siguientes razones:

  1. velocidad
  2. potencial de exponer alguna información de depuración
  3. etc

Algunos buenos candidatos para require-dev son:

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

puede ver lo que están haciendo los paquetes anteriores y verá por qué no los necesita en producción.

Vea más aquí: https://getcomposer.org/doc/04-schema.md

— fico7489
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.