Comment gérer les dépendances npm sans devenir fou ?

Je travaille sur un projet React assez gros et à chaque fois que j'installe un nouveau package, je me retrouve avec des conflits de versions complètement dingues. J'ai essayé d'utiliser npm ci mais ça ne marche pas toujours, surtout quand je collabore avec d'autres. Y a un moyen plus malin pour gérer ça sans tout refaire de zéro ?

3 réponses

★ Meilleure réponse

Ne touche jamais à `package-lock.json` à la main, c'est la première erreur !

Ce qui m'a vraiment aidé c'est d'utiliser `npm ci` en local et surtout de configurer un `.npmrc` avec `save-exact=true` dans le projet, comme ça quand tu installes des trucs ça sauvegarde les versions exactes au lieu des `^` et `~` qui créent des problèmes.

Après tu ajoutes un pre-commit hook avec husky qui empêche quelqu'un de commiter un `package-lock.json` cassé - c'est basique mais ça marche super bien parce que l'équipe ne peut pas tout foutre en l'air par accident. Et si vraiment tu dois ajouter un package, fais-le toujours avec `npm install --save-exact nom-du-package` et fais vérifier par quelqu'un avant de pusher !

Quand tu as ces conflits, c'est généralement ce qui se passe quand tu installes de nouveaux packages avec `npm install` sans vérifier ce que ça fait au `package-lock.json`, non?

Le problème, c'est qu'npm est un peu trop flexible par défaut. D'abord, assure-toi que tout le monde dans l'équipe utilise `npm ci` à la place de `npm install` quand vous travaillez sur un projet déjà lancé. La différence, c'est que `npm ci` lit exactement ce qu'il y a dans `package-lock.json` sans le modifier, alors que `install` se met à faire des upgrades de patch et de version mineure quand ça lui plaît. Si tu utilises `npm install` pour ajouter des trucs nouveaux et que vous pushez le lock file, les autres se retrouvent avec des versions différentes. De plus, committe toujours le `package-lock.json` dans le repository - ça semble évident mais beaucoup ne le font pas et après se demandent pourquoi le build échoue.

Pour les nouveaux packages, utilise `npm install --save-exact` si tu veux vraiment figer une version spécifique, ou jette un œil à des outils comme `npm audit` pour vérifier s'il y a des conflits de dépendances connus. Si le problème est vraiment grave avec plein de dépendances imbriquées, pense aussi à utiliser `npm dedupe` de temps en temps pour nettoyer l'arbre des dépendances. En vrai, tu pourrais aussi essayer pnpm ou yarn si tu es prête à changer d'écosystème - ils gèrent les dépendances de façon plus ordonnée - mais si tu veux rester avec npm, respecter le flux `ci` + `package-lock.json` dans git devrait résoudre la plupart des problèmes.

Francesca1967 asker Oui, on commit toujours le fichier lock. Le problème c'est que certains collègues utilisent encore `npm install` pour ajouter des nouveaux packages. Je vais essayer de standardiser sur `npm ci` et `--save-exact` pour les nouvelles dépendances.

Ce qui m'a vraiment sauvée, c'est d'utiliser `npm ci` en permanence, mais surtout d'insister pour que tout l'équipe fasse pareil - pas `npm install`.

À partir du moment où quelqu'un fait un `install` standard pour ajouter un package, le `package-lock.json` se modifie de façons bizarres et ensuite les autres se retrouvent à faire des merge conflicts insensés.

Ce que je fais, c'est utiliser `npm install <package> --save` seulement quand je dois ajouter des trucs nouveaux, et je laisse le lock file se mettre à jour, puis je commit tout ensemble avec les autres.

Mais le vrai trick, c'est de configurer les versions dans le `package.json` avec des ranges plus conservateurs - genre `^16.0.0` au lieu de `*` - comme ça React ne se met pas à jour vers une version mineure qui casse tout. J'ai vu des gros projets où ils ont juste mis un fichier `.npmrc` commun dans le repo avec `save-exact=true`, du coup chaque nouveau package se retrouve pinné à une version précise. C'est plus rigide, mais au moins tu ne deviens pas folle quand tu collabores.

Votre réponse

Se connecterpour répondre.