configurazione package.json

Se si sviluppa un'app Node.js con molti pacchetti npm, non è raro che si verifichino avvisi o errori quando si compila il progetto se uno o più pacchetti sono stati aggiornati. In alcuni casi, i risultati di un conflitto di versione o una versione del pacchetto sono stati deprecati. Ecco un paio di suggerimenti rapidi che consentono di configurare il file package.json e comprendere cosa accade quando vengono visualizzati avvisi o errori. Questa non è una guida completa per package.json ed è incentrata solo sul controllo delle versioni dei pacchetti npm.

Il sistema di controllo delle versioni dei pacchetti npm ha regole rigorose. Il formato della versione è il seguente:

[major].[minor].[patch]

Si supponga di avere un pacchetto nell'app con una versione 5.2.1. La versione principale è 5, la versione secondaria è 2 e la patch è 1.

• In un aggiornamento della versione principale, il pacchetto include nuove funzionalità incompatibili con le versioni precedenti, ovvero modifiche radicali.
• In un aggiornamento della versione secondaria sono state aggiunte nuove funzionalità al pacchetto compatibili con le versioni precedenti del pacchetto.
• In un aggiornamento delle patch sono incluse una o più correzioni di bug. Le correzioni di bug sono sempre compatibili con le versioni precedenti.

Vale la pena notare che alcune funzionalità del pacchetto npm hanno dipendenze. Ad esempio, per usare una nuova funzionalità del pacchetto del compilatore TypeScript (ts-loader) con webpack, è anche possibile aggiornare il pacchetto webpack npm e il pacchetto webpack-cli.

Per gestire il controllo delle versioni dei pacchetti, npm supporta diverse notazioni che è possibile usare nella package.json. Puoi usare queste notazioni per controllare il tipo di aggiornamenti del pacchetto che vuoi accettare nella tua app.

Si supponga di usare React e di includere il pacchetto npm react e react-dom. È possibile specificarlo in diversi modi nel file package.json. Ad esempio, è possibile specificare l'uso della versione esatta di un pacchetto come indicato di seguito.

"dependencies": {
  "react": "16.4.2",
  "react-dom": "16.4.2",
},

Usando la notazione precedente, npm otterrà sempre la versione esatta specificata, 16.4.2.

È possibile usare una notazione speciale per limitare gli aggiornamenti agli aggiornamenti delle patch (correzioni di bug). In questo esempio:

"dependencies": {
  "react": "~16.4.2",
  "react-dom": "~16.4.2",
},

si usa il carattere tilde (~) per indicare a npm di aggiornare un pacchetto solo quando viene applicata l'applicazione di patch. Npm può quindi aggiornare react 16.4.2 a 16.4.3 (o 16.4.4 e così via), ma non accetterà un aggiornamento alla versione principale o secondaria. Quindi, 16.4.2 non verrà aggiornato alla versione 16.5.0.

È anche possibile usare il simbolo di cursore (^) per specificare che npm può aggiornare il numero di versione secondaria.

"dependencies": {
  "react": "^16.4.2",
  "react-dom": "^16.4.2",
},

Usando questa notazione, npm può aggiornare react 16.4.2 a 16.5.0 (o 16.5.1, 16.6.0 e così via), ma non accetterà un aggiornamento alla versione principale. Quindi, 16.4.2 non verrà aggiornato alla versione 17.0.0.

Quando npm aggiorna i pacchetti, genera un file package-lock.json , che elenca le versioni effettive del pacchetto npm usate nell'app, inclusi tutti i pacchetti annidati. Mentre package.json controlla le dipendenze dirette per l'app, non controlla le dipendenze annidate (altri pacchetti npm richiesti da un determinato pacchetto npm). È possibile usare il file dipackage-lock.json nel ciclo di sviluppo se è necessario assicurarsi che altri sviluppatori e tester usino i pacchetti esatti usati, inclusi i pacchetti annidati. Per altre informazioni, vedere package-lock.json nella documentazione di npm.

Per Visual Studio, il file package-lock.json non viene aggiunto al progetto, ma è possibile trovarlo nella cartella del progetto.