Come gestire le dipendenze npm senza impazzire?

Francesca1967 IT 📗 Studente 👁 70 ⚑ Segnala Programmazione

Sto lavorando su un progetto React abbastanza grande e ogni volta che installo un nuovo package mi ritrovo con conflitti di versioni assurdi. Ho provato a usare npm ci ma non sempre funziona, soprattutto quando collaboro con altri. C'è un modo più intelligente per gestire questa situazione senza rifare tutto da capo?

3 risposte

★ Miglior risposta

Non toccare il `package-lock.json` a mano mai, è il primo errore!

Quello che ha aiutato parecchio me è usare `npm ci` in locale e soprattutto configurare un `.npmrc` con `save-exact=true` nel progetto, così quando installi roba nuova salva le versioni esatte invece che con i `^` e `~` che causano casino.

Poi aggiungi un pre-commit hook con husky che blocca chi prova a committare `package-lock.json` rotto - banale ma funziona da paura perché il team non può rovinare tutto per sbaglio.

E se proprio devi aggiungere un package, fallo sempre con `npm install --save-exact nomepacchetto` e fai controllare a qualcuno prima di pushare!

Quando hai questi conflitti, di solito accade quando installi package nuovi con `npm install` senza controllare cosa fa alla `package-lock.json`, giusto?

Il problema è che npm è un po' troppo flexible di default. Prima cosa, assicurati che tutti nel team usino `npm ci` al posto di `npm install` quando lavorano su un progetto già avviato. La differenza è che `npm ci` legge esattamente quello che c'è in `package-lock.json` senza modificarlo, mentre `install` si mette a fare gli upgrade di patch e minor version quando gli gira. Se usi `npm install` per aggiungere roba nuova e poi pushate il lock file, gli altri si ritrovano versioni diverse. Inoltre, committa sempre il `package-lock.json` nel repository - suona banale ma molti non lo fanno e poi si chiedono perché il build fallisce.

Per i nuovi package, usa `npm install --save-exact` se vuoi davvero freezare una versione specifica, oppure dai un'occhiata a tool tipo `npm audit` per controllare se ci sono dependency conflitti noti. Se il problema è molto grave con tante dipendenze annidate, considera anche di usare `npm dedupe` ogni tanto per pulire l'albero delle dipendenze. In realtà, potresti anche provare pnpm o yarn se sei disposto a cambiare ecosystem - gestiscono le dipendenze in maniera più ordinata - ma se vuoi restare con npm, rispettare il flusso `ci` + `package-lock.json` nel git dovrebbe risolvere la maggior parte dei casini.

Francesca1967 asker Sì, committiamo sempre il lock file. Il problema è che alcuni colleghi usano ancora `npm install` per aggiungere package nuovi. Proverò a standardizzare su `npm ci` e `--save-exact` per i nuovi package.

La cosa che mi ha salvato davvero è usare `npm ci` sempre, ma soprattutto insistere che tutto il team lo faccia - non `npm install`.

Nel momento in cui qualcuno fa un `install` standard per aggiungere un package, la `package-lock.json` si modifica in modi strani e poi gli altri si ritrovano a fare merge conflicts assurdi.

Quello che faccio è usare `npm install <package> --save` solo quando devo aggiungere roba nuova, e lascio che il lock file si aggiorni, poi committa tutto insieme agli altri.

Ma il trick vero è configurare le versioni nel `package.json` con range più conservative - tipo `^16.0.0` invece di `*` - così React non mi si aggiorna a una minor version that breaks everything. Ho visto progetti grandi dove semplicemente hanno messo un file `.npmrc` comune nel repo con `save-exact=true`, così ogni package nuovo viene pinato a una versione precisa. È più rigido, ma almeno non impazzisci quando collabori.

La tua risposta

Accediper rispondere.