Composer: require-dev no anula require en composer.json

Creado en 29 feb. 2016  ·  3Comentarios  ·  Fuente: composer/composer

Hola,
Estaba tratando de usar require-dev en mi entorno local y en mi entorno UAT, pero cada vez que uso la "actualización del compositor" obtengo errores si tengo algunos paquetes en require-dev que anulan los paquetes require.
Aquí hay un ejemplo de mi composer.json:

... "require": {
        "php": ">=5.5.0",
        "wp/wordpress": "4.4.2",
        "wp/amazon-web-services": "0.2.2",
        "wp/members": "^1.0.2",
        "wp/nextgen-gallery-custom-fields": "^1.2.4",
        "wp/wpml-string-translation": "^2.2.6",
        "wp/sitepress-multilingual-cms": "^3.2.7",
        "wp/wpml-translation-management": "^2.0.5"
},
    "require-dev": {
        "wp/wp-functional-tests": "^1.0.0",
    "wp/sitepress-multilingual-cms": "dev-testing-3.3.6",
    "wp/wpml-string-translation": "dev-testing-2.3.6.1",
        "wp/wpml-translation-management": "dev-testing-2.1.5"
}, ...

cuando ejecuto una actualización del compositor, aparece este error:

Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating wp/wpml-string-translation (2.3.2 => dev-testing-2.3.6.1 ddc3c6b)
    Checking out ddc3c6b3923fe47deda4d8d....

  - Updating wp/sitepress-multilingual-cms (3.3.1 => dev-testing-3.3.6 164cab6)
    Checking out 164cab6c3c756ba031c58a3....



  [Composer\DependencyResolver\SolverProblemsException]
    Problem 1
      - The requested package wp/wpml-string-translation ^2.2.6 could not be found.
    Problem 2
      - The requested package wp/sitepress-multilingual-cms ^3.2.7 could not be found.
    Problem 3
      - The requested package wp/wpml-translation-management ^2.0.5 could not be found.
  Potential causes:
   - A typo in the package name
   - The package is not available in a stable-enough version according to your minimum-stability setting
     see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
  Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

¿Me estoy perdiendo de algo? ¿No se supone que require-dev anula los plugins requeridos? ¿Por qué simplemente no encuentra mis versiones estables? (que, por supuesto, encuentre si no estoy usando require-dev)

Muchas gracias

Support

Comentario más útil

Entonces, ¿qué debo hacer si quiero usar la integración continua y construir mi paquete en un entorno diferente como prod, stage, dev, uat donde stage y prod requieren versiones estables y en uat y dev quiero probar uno diferente? ¿Debo hacer siempre diferentes paquetes de forma independiente?
Sería genial usar require/require-dev para establecer algún tipo de jerarquía (en el contexto de integración continua)

Todos 3 comentarios

No está anulando, no, está fusionando los dos, por lo que si no coinciden, eso crea un problema. Requerir algo tanto en require como en require-dev no es realmente un caso de uso admitido y es muy probable que genere problemas. Le aconsejaría que simplemente elija si un paquete es necesario solo para el desarrollo o no, y luego lo incluya en la lista solo una vez.

Entonces, ¿qué debo hacer si quiero usar la integración continua y construir mi paquete en un entorno diferente como prod, stage, dev, uat donde stage y prod requieren versiones estables y en uat y dev quiero probar uno diferente? ¿Debo hacer siempre diferentes paquetes de forma independiente?
Sería genial usar require/require-dev para establecer algún tipo de jerarquía (en el contexto de integración continua)

Su problema está en el flujo de trabajo, no en la técnica: debe adoptar un flujo de trabajo basado en sucursales para mantener diferentes etapas de desarrollo. Por lo general, se desarrolla en master , se prueba en ramas de versión como 1.0.x y se publica en etiquetas. Git facilita ese flujo de trabajo al fusionar las ramas de problemas en master y confirma en el maestro de nuevo las ramas de la versión. Las herramientas de CI como Travis están preparadas para monitorear todas las ramas y nuevas etiquetas para un repositorio determinado. Como puede tener diferentes versiones de composer.json en cada confirmación y rama, esto resuelve su problema de inmediato.

En los raros casos restantes en los que le gustaría tener varias instancias diferentes de composer.json , por ejemplo, para probar una implementación con todos los paquetes sugeridos instalados, podría tener otro como composer-with-suggests.json y usar el COMPOSER variable de entorno :

COMPOSER=composer-with-suggest.json composer install
¿Fue útil esta página
0 / 5 - 0 calificaciones