¿Cómo gestionar las dependencias de npm sin volverse loco?

Francesca1967 IT 📗 Estudiante 👁 71 ⚑ Denunciar Programación

Estoy trabajando en un proyecto React bastante grande y cada vez que instalo un nuevo paquete me encuentro con conflictos de versiones absurdos. Intenté usar npm ci pero no siempre funciona, especialmente cuando colaboro con otros. ¿Hay alguna forma más inteligente de manejar esta situación sin tener que rehacer todo desde cero?

3 respuestas

★ Mejor respuesta

Nunca toques `package-lock.json` a mano, ¡ese es el primer error! Lo que me ayudó un montón fue usar `npm ci` en local y sobre todo configurar un `.npmrc` con `save-exact=true` en el proyecto, así cuando instalas cosas nuevas guarda las versiones exactas en vez de con los `^` y `~` que causan un desastre.

Luego añades un pre-commit hook con husky que bloquea a quien intente hacer commit de `package-lock.json` roto - algo básico pero funciona de maravilla porque el equipo no puede arruinarlo todo por accidente. ¡Y si realmente tienes que añadir un paquete, hazlo siempre con `npm install --save-exact nomepaquete` y que alguien lo revise antes de pushear!

Cuando tienes estos conflictos, generalmente pasa cuando instalas paquetes nuevos con `npm install` sin revisar qué hace con `package-lock.json`, ¿verdad?

El problema es que npm es demasiado flexible por defecto. Lo primero, asegúrate de que todos en el equipo usen `npm ci` en lugar de `npm install` cuando trabajen en un proyecto ya iniciado. La diferencia es que `npm ci` lee exactamente lo que hay en `package-lock.json` sin modificarlo, mientras que `install` se pone a hacer upgrades de versiones patch y minor cuando le da la gana. Si usas `npm install` para añadir cosas nuevas y luego pusheáis el lock file, los otros se encuentran versiones diferentes. Además, siempre commitea el `package-lock.json` en el repositorio - suena obvio pero muchos no lo hacen y después se preguntan por qué el build falla.

Para los paquetes nuevos, usa `npm install --save-exact` si quieres realmente congelar una versión específica, o echa un vistazo a herramientas como `npm audit` para verificar si hay conflictos de dependencias conocidos. Si el problema es muy grave con un montón de dependencias anidadas, considera también usar `npm dedupe` de vez en cuando para limpiar el árbol de dependencias. En realidad, podrías probar pnpm o yarn si estás dispuesto a cambiar de ecosistema - gestionan las dependencias de manera más ordenada - pero si quieres quedarte con npm, respetar el flujo `ci` + `package-lock.json` en git debería resolver la mayoría de los líos.

Francesca1967 asker Sí, siempre hacemos commit del archivo de bloqueo. El problema es que algunos colegas todavía usan `npm install` para agregar paquetes nuevos. Intentaré estandarizar en `npm ci` y `--save-exact` para los paquetes nuevos.

Lo que realmente me salvó fue usar siempre `npm ci`, pero sobre todo insistir en que todo el equipo lo hiciera - nada de `npm install`. En el momento en que alguien hace un `install` estándar para agregar un paquete, el `package-lock.json` se modifica de formas raras y después los otros terminan con merge conflicts absurdos.

Lo que hago es usar `npm install <package> --save` solo cuando necesito agregar cosas nuevas, y dejo que el lock file se actualice, después commiteo todo junto con los demás.

Pero el verdadero truco es configurar las versiones en el `package.json` con rangos más conservadores - tipo `^16.0.0` en lugar de `*` - así React no se me actualiza a una versión menor que rompe todo. He visto proyectos grandes donde simplemente pusieron un archivo `.npmrc` común en el repo con `save-exact=true`, así cada paquete nuevo queda pinado a una versión precisa. Es más rígido, pero al menos no te vuelves loco cuando colaboras.

Tu respuesta

Iniciar sesiónpara responder.