¿Cómo implementar correctamente cuando se utiliza el conmutador de desarrollo/producción de Composer?
Composer tiene la opción de cargar varias dependencias solo mientras está en desarrollo, por lo que las herramientas no se instalarán en producción (en el servidor en vivo). Esto es (en teoría) muy útil para scripts que solo tienen sentido en desarrollo, como pruebas, herramientas de datos falsos, depuradores, etc.
El camino a seguir es agregar un require-devbloque adicional con las herramientas que necesitas en desarrollo:
"require-dev": {
"codeception/codeception": "1.6.0.3"
}
y luego (teóricamente) cargar estas dependencias a través de
composer install --dev
Problema y pregunta:
Composer ha cambiado el comportamiento instally updatedramáticamente en 2013, require-devlas dependencias ahora están instaladas de forma predeterminada (!), siéntase libre de crear un compositor.json con un require-devbloque y realizar un composer installpara reproducir.
La forma más aceptada de implementación es presionar al compositor. lock (que contiene la configuración actual del compositor) y luego haga una composer installen el servidor de producción, esto también instalará el material de desarrollo.
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias -dev?
Nota: Estoy intentando crear una sesión de preguntas y respuestas canónica aquí para aclarar la extraña implementación de Composer. No dudes en editar esta pregunta.
Por qué
En mi humilde opinión, existe una buena razón por la que Composer usará la --devbandera de forma predeterminada (durante la instalación y actualización) hoy en día. Composer se ejecuta principalmente en escenarios donde este es el comportamiento deseado:
El flujo de trabajo básico de Composer es el siguiente:
- Se inicia un nuevo proyecto:
composer.phar install --devlos archivos json y lock se envían a VCS. - Otros desarrolladores comienzan a trabajar en el proyecto: compra de VCS y
composer.phar install --dev. - Un desarrollador agrega dependencias:,
composer.phar require <package>agregue--devsi desea el paquete en larequire-devsección (y confirme). - Otros van junto: (pagar y)
composer.phar install --dev. - Un desarrollador quiere versiones más nuevas de dependencias:
composer.phar update --dev <package>(y confirmar). - Otros van junto: (pagar y)
composer.phar install --dev. - El proyecto está implementado:
composer.phar install --no-dev
Como puede ver, la --devbandera se usa (mucho) más que la --no-devbandera, especialmente cuando crece la cantidad de desarrolladores que trabajan en el proyecto.
Implementación de producción
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias "dev"?
Bueno, el archivo composer.jsony composer.lockdebe enviarse a VCS. No lo omita composer.lockporque contiene información importante sobre las versiones de paquetes que deben usarse.
Al realizar una implementación de producción, puedes pasar la --no-devbandera a Composer:
composer.phar install --no-dev
El composer.lockarchivo puede contener información sobre paquetes de desarrollo. Esto no importa. La --no-devbandera se asegurará de que esos paquetes de desarrollo no estén instalados.
Cuando digo "implementación en producción", me refiero a una implementación que está destinada a ser utilizada en producción. No estoy discutiendo si se composer.phar installdebe hacer en un servidor de producción o en un servidor de prueba donde se puedan revisar las cosas. Ese no es el alcance de esta respuesta. Simplemente estoy señalando cómo hacerlo composer.phar installsin instalar dependencias "dev".
Fuera de contexto
La --optimize-autoloaderbandera también podría ser deseable en producción (genera un mapa de clases que acelerará la carga automática en su aplicación):
composer.phar install --no-dev --optimize-autoloader
O cuando se realiza la implementación automatizada:
composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --optimize-autoloader
Si su código base lo admite, puede cambiarlo --optimize-autoloaderpor --classmap-authoritative. Más información aquí
En realidad, recomiendo encarecidamente CONTRA la instalación de dependencias en el servidor de producción.
Mi recomendación es verificar el código en una máquina de implementación, instalar las dependencias según sea necesario (esto incluye NO instalar dependencias de desarrollo si el código pasa a producción) y luego mover todos los archivos a la máquina de destino.
¿Por qué?
- en hosting compartido, es posible que no puedas acceder a una línea de comando
- incluso si lo hiciera, PHP podría estar restringido allí en términos de comandos, memoria o acceso a la red
- Es probable que las herramientas CLI del repositorio (Git, Svn) no estén instaladas, lo que fallaría si su archivo de bloqueo ha registrado una dependencia para verificar una determinada confirmación en lugar de descargar esa confirmación como ZIP (usó --prefer-source, o Composer tenía no hay otra manera de conseguir esa versión)
- Si su máquina de producción se parece más a un pequeño servidor de prueba (piense en una microinstancia de Amazon EC2), probablemente ni siquiera haya suficiente memoria instalada para ejecutar.
composer install - Mientras que Composer intenta no romper las cosas, ¿qué te parece terminar con un sitio web de producción parcialmente roto porque algunas dependencias aleatorias no se pudieron cargar durante la fase de instalación de Composers?
En pocas palabras: utilice Composer en un entorno que pueda controlar. Su máquina de desarrollo califica porque ya tiene todo lo necesario para operar Composer.
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias -dev?
El comando a utilizar es
composer install --no-dev
Esto funcionará en cualquier entorno, ya sea el propio servidor de producción, una máquina de implementación o la máquina de desarrollo que se supone debe realizar una última comprobación para determinar si algún requisito de desarrollo se utiliza incorrectamente para el software real.
El comando no instalará ni desinstalará activamente los requisitos de desarrollo declarados en el archivo compositor.lock.
Si no le importa implementar componentes de software de desarrollo en un servidor de producción, ejecutarlo composer installharía el mismo trabajo, pero simplemente aumentaría la cantidad de bytes movidos y también crearía una declaración de cargador automático más grande.
