Una guida a npm: The Node.js Package Manager

JavaScript è facilmente il linguaggio più utilizzato quando si parla di sviluppo di siti web e applicazioni web. La moltitudine di risorse è sbalorditiva, e ancor di più il numero di biblioteche disponibili.

All'inizio, queste librerie sono poche e di facile manutenzione; tuttavia, abbastanza presto si instaura un inferno di dipendenza ed è necessaria una soluzione più matura.

Immettere il Node Package Manager (npm), un gestore di pacchetti JavaScript utilizzato in particolare insieme a Node.js, sebbene possa essere utilizzato anche in modo indipendente. Ti dà un controllo eccezionale sulle dipendenze del tuo progetto e fornisce un ottimo modo per contribuire al mondo open source.

Puoi iniziare semplicemente eseguendo npm install <package name> e inserendolo nel tuo file JavaScript.

Vuoi installare una versione specifica? Nessun problema. Esegui npm install <package name>@1.2.3 .

Vuoi installare un pacchetto a livello globale (come Mocha o Angular-CLI)? Basta aggiungere un -g in questo modo: npm install -g angular-cli mocha .

Certo, la maggior parte dei casi d'uso si ferma a un'installazione di npm e non c'è bisogno di nient'altro. Tuttavia, npm ha un sacco di funzionalità aggiuntive, che ti guiderò attraverso, evidenziando quelle che considero essenziali, davvero utili o semplicemente fantastiche.

Comandi CLI

La CLI è il luogo in cui gli utenti trascorrono la maggior parte del loro tempo a interagire con npm e la sua interfaccia di aiuto è effettivamente utile.

La richiesta di aiuto ( npm help ) genera un'intera gamma di opzioni e l'esecuzione di npm help-search <searchText> fornisce un elenco di risultati di ricerca direttamente dal markdown npm.

Ecco i comandi principali che si distinguono.

• install : è menzionato qui a causa della sua assoluta necessità quando si lavora con npm. Utilizzato per installare un nuovo pacchetto localmente o globalmente (quando si aggiunge -g ) o per installare le dipendenze elencate nel file package.json (ne parleremo più avanti).

• uninstall : anche questo è essenziale. Viene utilizzato per eliminare un pacchetto specifico dalla directory node_modules localmente o globalmente (quando si aggiunge -g ).

• access : questo è il parco giochi degli amministratori delle autorizzazioni utente npm all'interno del contesto npm-organizations e pacchetti con ambito (privato). Roba davvero potente. Usato insieme a adduser , owner , team , ecc., offre un controllo granulare su chi ha accesso a cosa.

• bin : dove diavolo sono installati i pacchetti? Esegui questo comando per vedere il percorso del file assoluto.

• cache : se inizi a installare i pacchetti da npm a sinistra, a destra e al centro, questo comando è molto utile. Chiamalo con il sottocomando ls per visualizzare un elenco di pacchetti memorizzati nella cache locale o con il sottocomando clean per cancellare tutti i pacchetti che si trovano nella cache. Quando il registro npm era ancora un po' instabile, questo era essenziale per tornare a un ambiente stabile o per ripristinare le cose quando non si impostavano correttamente le autorizzazioni npm.

• config : entreremo nelle diverse opzioni di configurazione in seguito, ma questo comando si occupa principalmente delle proprietà di configurazione persistenti nel file di configurazione locale o globale utilizzando i sottocomandi set , get o delete .

• dedupe o ddp : quando si lavora su un progetto per un lungo periodo di tempo e si installano pacchetti direttamente da npm, questo comando percorrerà l'albero dei pacchetti locale e tenterà di semplificare le dipendenze.

• link : quando stai sviluppando il tuo pacchetto npm, questo ti permette di creare un collegamento simbolico al contesto globale in modo che possa essere testato come se fosse installato globalmente dal registro npm. Ad esempio, se stai scrivendo uno strumento di assemblaggio in un nodo su cui è installata una CLI a livello globale, puoi eseguire questo comando e testare il comportamento della tua CLI senza doverla prima distribuire.

• ls : è usato per visualizzare le dipendenze dei pacchetti e le loro dipendenze, in una struttura ad albero. È bello da vedere ed è anche utile per i confronti con altri progetti.

• outdated : viene utilizzato per valutare lo stato corrente delle dipendenze installate e se sono obsolete o meno. Nei progetti in cui l'elenco delle dipendenze radice è lungo centinaia di righe, un controllo manuale sui pacchetti è quasi impossibile. L'aggiunta -g --depth=0 a questo comando consente di controllare anche i pacchetti installati a livello globale.

• publish : questo comando è essenziale quando si sviluppa il proprio pacchetto per npm. Fa esattamente come suggerisce il nome; pubblica il tuo pacchetto nel registro npm.

• search : usa questo per cercare nel registro tutti i pacchetti contenenti il ​​testo fornito nel terzo argomento.

• shrinkwrap : In breve, questo comando ti consente di bloccare specifiche versioni di dipendenze in un pacchetto in ordine, in modo che un numero semver rilassato (versione semantica) non rompa il codice di produzione.

• star : Ti piace davvero un pacchetto che stai usando? Usa questo comando per mostrare il tuo apprezzamento direttamente dal terminale, che poi si riflette sulla pagina del pacchetto nel registro npm.

• update : Questo di solito segue il comando outdated per aggiornare eventuali pacchetti obsoleti.

• version : questo ti dà una scorciatoia per eseguire il bump della proprietà della versione package.json ed eseguire un tag git tutto in uno.

Si noti che la maggior parte di questi comandi può accettare sottocomandi e/o configurazioni e questo elenco non è affatto una discussione finale sulla CLI.

npm-config

La configurazione è una parte importante di npm e ci sono diversi modi in cui è possibile impostare le variabili di configurazione.

Configurazione tramite CLI e variabili ambientali

Innanzitutto, la configurazione può essere impostata tramite la CLI dal terminale.

In genere sarebbe simile a questo: npm <command> --<configuration option> [<optional value>] .

Se il valore non è specificato, l'opzione sarà impostata su true per impostazione predefinita.

Ad esempio, supponiamo che tu stia lavorando su un pacchetto npm con ambito (privato) e decidi di pubblicarlo come pacchetto pubblico.

Questo può essere fatto facilmente aggiungendo --access=public al comando di publish . Se non specificassimo che la proprietà fosse pubblica, il valore predefinito sarebbe limitato (privato).

La configurazione aggiunta ad altri comandi come questo non persiste ovunque, quindi può diventare noioso impostare una serie di configurazioni tramite la CLI.

In questi casi, potrebbe essere meglio impostare la configurazione utilizzando le variabili ambientali.

Qualsiasi variabile ambientale impostata con il prefisso npm_config_ verrà utilizzata per configurare npm.

Ad esempio: export npm_config_registry=localhost:4321 imposterebbe l'opzione di configurazione del registro a livello globale e quando npm viene eseguito utilizzerà il registro npm situato su localhost sulla porta 4321.

Configurazione tramite il file npmrc

Puoi anche impostare le opzioni di configurazione utilizzando lo speciale file .npmrc , che può essere impostato a diversi livelli a seconda delle tue esigenze:

• Livello di progetto: nella radice del codice di un progetto insieme al relativo file package.json , in genere path/to/project/.npmrc
• Livello utente: la directory che configura l'account di un utente specifico, in genere ~/.npmrc
• Livello globale: la directory in cui npm cerca le configurazioni globali, in genere $PREFIX/etc/npmrc
• Livello integrato: fai attenzione. Questa configurazione non è solo globale, ma fa anche parte del codice sorgente npm e la best practice consiglia (in realtà richiede) di non modificare il codice di cui non siamo responsabili per la manutenzione. In genere può essere trovato in /path/to/npm/npmrc .

Le impostazioni di configurazione nel file .npmrc possono essere modificate e mantenute utilizzando la CLI eseguendo un comando in questo formato: npm config set <key> <value> .

Ad esempio, puoi eseguire npm config set access public per rendere permanentemente pubblica la configurazione di pubblicazione di un pacchetto con ambito (privato).

Per impostazione predefinita, questo comando persiste la configurazione localmente (la configurazione a livello di utente come descritto sopra), ma puoi aggiungere -g per mantenerla a livello globale.

Quando la configurazione persistente deve avvenire a livello di progetto oa livello integrato, il file .npmrc deve essere modificato utilizzando un editor di testo.

Configurazione tramite package.json

Infine, la configurazione può essere impostata dal file package.json . Tuttavia, questo è usato raramente (e dovrebbe essere usato solo se esplicitamente richiesto), perché un file .npmrc a livello di progetto è il posto convenzionalmente preferito per impostare la configurazione del pacchetto.

Notevoli impostazioni di configurazione

• access : come discusso in precedenza, viene utilizzato per impostare le autorizzazioni.

• always-auth : è importante notare che questa impostazione predefinita è false. Quando è impostato su true, npm richiederà sempre l'autenticazione quando si contatta il registro.

• ca : impostazione predefinita per l'autorità di certificazione (CA) npm. Può essere modificato in null per consentire l'accesso solo ai registrar noti o a un certificato CA specifico per concedere l'accesso solo a quello specifico. Questa impostazione, insieme a cafile , cert e strict-ssl , sono usati raramente, ma parlano dell'aspetto di sicurezza e affidabilità di npm, consentendo la tranquillità di sapere che il pacchetto che stai installando proviene dall'origine che ti aspetti.

• color : l'impostazione predefinita è true, dandoti una pausa dalla desolazione standard del terminale colorando lo stdout consentito dai descrittori di file tty. Se impostato su false il terminale rimane opaco. Quando è impostato su always , viene sempre visualizzato a colori.

• depth : questa impostazione consente un controllo granulare su ciò che vedi con i comandi ricorsivi, come ls e outdated , assegnando la profondità con cui vengono eseguiti. Un valore di 0 valuterà solo il primo livello di dipendenze, mentre infinity (impostazione predefinita) causerà la valutazione di tutti i livelli di dipendenze. L'eccezione a questa regola è quando la si utilizza con outdated ; in tal caso, l'infinito viene interpretato come 0 per garantire un output più rilevante.

• dev : questo è impostato su false per impostazione predefinita, ma quando è impostato su true (quando si esegue un'installazione npm install ) tutte le dipendenze di sviluppo nel file package.json verranno installate insieme alle normali dipendenze.

• dry-run : quando questa impostazione è impostata su true, npm non apporterà alcuna modifica al pacchetto ma ti dirà invece cosa avrebbe fatto. Questo può essere molto utile quando si eseguono determinati comandi, come dedupe o update .

  

• git-tag-version : è impostato su true per impostazione predefinita. Questa impostazione contrassegna una versione in git durante l'esecuzione del comando npm version . Se stai usando npm come gestore di pacchetti per un progetto di grandi dimensioni che ha taggato le versioni in git, può farti risparmiare tempo e ricorda di aggiornare il file package.json per te.

• loglevel : per impostazione predefinita, è impostato su warn , che fornisce un output di errore e avviso durante l'esecuzione dei comandi npm. Altre impostazioni includono silent , che non fornisce alcun output; error , che registra solo gli errori nell'output; http , che annuncia solo errori di richiesta http; info , per ottenere un output informativo); verbose , che registra quasi tutto; e silly , che, come suggerisce il nome, fornisce una quantità sciocca di output e poi alcuni.

• production : quando è impostato su true, npm agisce di conseguenza ed esegue tutti i comandi in modalità produzione. Ciò significa che lo sviluppo o le dipendenze facoltative non verranno installate, né verranno eseguite attività relative allo sviluppo.

• rollback : se impostato su true, tutte le installazioni non riuscite vengono rimosse. Questo è utile quando un'installazione delle dipendenze non riesce. A seconda del livello di registrazione, dovresti essere in grado di vedere quali installazioni non sono riuscite, prenderne nota ed eseguire il comando npm install con l'opzione rollback impostata su true. Quindi, con le tue note e un'installazione dry-run (come descritto sopra), puoi quindi eseguire il debug del problema.

• save : When installing a package directly from the registry, you can append –save to the command which will add the installed package to the dependencies option in the file. For example, file. For example, npm install lodash` aggiungerà lodash alle tue dipendenze.

• save-dev : simile all'opzione di salvataggio della configurazione, aggiungi --save-dev durante l'installazione di un pacchetto e verrà quindi aggiunto all'opzione devDependencies nel file package.json .

• save-optional : simile all'opzione di salvataggio della configurazione, aggiungi --save-optional durante l'installazione di un pacchetto e verrà quindi aggiunto all'opzione optionalDependencies nel file package.json .

• save-exact : durante l'installazione dei pacchetti, le opzioni save , save-dev e save-optional modificano il file package.json inserendo il pacchetto installato nella rispettiva proprietà con un operatore di intervallo semver. Quando si richiama l'impostazione di configurazione 'save-exact' con un valore true, insieme a una delle impostazioni sopra menzionate, viene utilizzato un numero di versione specifico, ignorando l'intervallo di tempo.

• save-prefix : imposta l'operatore di intervallo semver quando si utilizza save , save-dev o save-optional . L'impostazione predefinita è ^ , consentendo l'esecuzione di aggiornamenti minori sui pacchetti durante l'installazione. Questo può essere impostato su qualsiasi operatore di intervallo semver prefissato valido.

• tag-version-prefix : l'impostazione predefinita convenzionale è v , che specifica cosa viene anteposto alla versione del tag git quando si esegue npm version .

Aggiornamento di npm Utilizzo di npm

Puoi anche usare npm per aggiornarsi.

Esegui semplicemente npm install -g npm@latest e npm verrà aggiornato all'ultima versione stabile. È importante notare che ogni versione di Node.js viene fornita con una versione specifica di npm e, secondo la mia esperienza, non dovresti pasticciare troppo con quell'abbinamento.

Alla fine della giornata, la mia raccomandazione è di attenersi all'abbinamento come previsto.

Quando si utilizza npm come strumento autonomo, assicurarsi di comprendere le implicazioni dell'utilizzo di qualsiasi versione si scelga. C'è un ottimo strumento per gestire diverse versioni di Node.js (e a loro volta versioni npm) sullo stesso sistema chiamato nvm.

Il file package.json

Il file package.json è l'elemento cruciale che collega tutto insieme.

È un requisito per la pubblicazione di un pacchetto nel registro npm ed è qui che prende vita la parte di gestione delle dipendenze.

Ha due campi obbligatori, vale a dire "nome" e "versione", e insieme queste proprietà dovrebbero essere un identificatore univoco.

Il campo del nome deve rispettare determinate regole, come definito dalla documentazione npm sulla denominazione, e il campo della versione è soggetto alle specifiche più semver.

Inoltre, puoi avere un elenco di dipendenze lungo un miglio e definire una versione specifica da utilizzare per ciascuna di esse, utilizzando le versioni semver e gli operatori di intervallo. Ecco un elenco di altre proprietà degne di nota.

"principale"

"main" definisce il punto di ingresso per l'applicazione, che per impostazione predefinita è index.js . A seconda della convenzione o del framework, potrebbe essere app.js o main.js . Ovviamente puoi farne quello che vuoi.

"script"

Questa è una proprietà sottovalutata.

In primo luogo, può essere utilizzato per fare cose in fase di prepubblicazione.

In secondo luogo, fornisce un luogo in cui è possibile alias una serie di comandi utilizzati di frequente, che vanno dalle attività di compilazione (definite in gulp o grunt), attivando l'installazione di altre dipendenze (con qualcosa come bower), avviando un server di sviluppo con webpack o eseguire una serie di comandi bash.

"dipendenze"

Questa proprietà è un elenco di pacchetti necessari per l'applicazione, insieme al numero di semver compatibile. È una proprietà notevole perché può essere modificata dal terminale quando si installano i pacchetti locali.

Questo viene fatto aggiungendo --save (o la scorciatoia -S ) alla fine del comando npm install .

Quando si esegue questa operazione, i nuovi pacchetti installati vengono aggiunti all'elenco delle dipendenze nel file package.json .

Allo stesso modo, una dipendenza può anche essere rimossa aggiungendo --save durante l'esecuzione del comando npm uninstall .

È importante essere consapevoli dei modelli di controllo delle versioni di ciascuna delle dipendenze e del loro significato.

Se la regola semver è troppo rigida, perdi nuove funzionalità e miglioramenti, mentre se la regola semver è troppo rilassata, è possibile installare una versione non funzionante di un pacchetto lungo la linea.

Un'installazione di un pacchetto non funzionante può rivelarsi piuttosto difficile da risolvere, specialmente quando viene utilizzata la versione ridotta del pacchetto.

"DevDependencies"

Separata dalla proprietà delle dipendenze, la proprietà "devDependencies" consente di definire le dipendenze che vengono utilizzate solo durante la fase di sviluppo e non sono necessarie per la build di produzione (come ESLint, pacchetti grunt-contrib e Protractor). Proprio come con le dipendenze, questa proprietà può essere modificata dal terminale aggiungendo --save-dev (o l'abbreviazione -D ) alla fine del comando npm install o del comando npm uninstall . La stessa cautela si applica al controllo delle versioni menzionato nelle dipendenze.

"bidone"

Qui è dove puoi specificare i file eseguibili del tuo pacchetto, come il percorso di un'utilità CLI. Questa proprietà dice a npm di creare collegamenti simbolici locali o globali ai tuoi eseguibili quando il tuo pacchetto è installato.

"configurazione"

Come discusso in precedenza, è qui che definisci le impostazioni di configurazione tramite il tuo file package.json .

"privato"

Se impostato su true, npm rifiuterà di pubblicare il pacchetto.

Questo non deve essere confuso con l'impostazione della configurazione di accesso.

Questa è un'impostazione utile quando si dispone di un progetto che utilizza npm insieme al relativo package.json ma non è destinato a essere pubblicato nel registro npm, con ambito o pubblico.

Se la tua intenzione cambia, cambia semplicemente l'impostazione su false e sarai in grado di pubblicare il tuo pacchetto.

Proprietà personalizzate

Il file package.json accetta anche proprietà personalizzate, purché il nome non sia già definito o riservato.

Sviluppo del proprio pacchetto npm

L'ecosistema npm è pieno di pacchetti, scritti da migliaia di sviluppatori diversi in tutto il mondo. Ciascuno risolve una sorta di problema, fornendo un'astrazione o presentando un'implementazione di qualcosa.

È probabile che, a un certo punto, anche tu vorrai sviluppare il tuo pacchetto da condividere.

Innanzitutto, devi creare un file package.json con le proprietà minime richieste di "name" e "version", quindi la proprietà "main" per specificare il punto di ingresso, ad esempio index.js.

Scrivi il tuo codice in quel file index.js, accedi con il tuo account utente npm o crea un nuovo utente dal terminale e sei pronto per pubblicarlo nel registro npm.

I pacchetti possono essere pubblici o privati.

I pacchetti pubblici possono essere pubblicati gratuitamente e possono essere utilizzati da tutti.

I pacchetti privati, chiamati pacchetti con ambito, possono essere pubblicati solo se hai pagato l'utente dei moduli privati ​​e possono essere identificati dal distinto @username/ che è anteposto al nome del pacchetto.

I pacchetti con ambito possono anche essere pubblicati pubblicamente chiamando il comando publish con --access=public .

Inoltre, se dedichi più tempo a espandere e migliorare la base di codice del tuo pacchetto, ed è ora di pubblicare una nuova versione, devi semplicemente modificare la versione (secondo le regole e le convenzioni di semver) del pacchetto nel package.json file e digita npm publish .

Puoi anche utilizzare l'interfaccia della riga di comando e chiamare npm version <update_type> , dove update_type è patch , minor o major , come descritto da semver, e questo quindi incrementa automaticamente il numero di versione nel file package.json .

npm Organizzazioni

Ancora una volta, la documentazione npm per questo è eccellente e sarebbe inutile ripetere le loro parole.

Ciò che si può dire delle organizzazioni nel contesto npm è che è estremamente fine e, se gestiti correttamente, team e individui di grandi dimensioni, che lavorano su pacchetti con ambito o pubblici sotto un unico nome, possono essere gestiti e limitati molto bene.

Sebbene sia complesso da padroneggiare, è molto gratificante.

Il potere di npm

In definitiva, la documentazione fornita da npm è ampia e dovrebbe essere consultata per i dettagli, ma questo articolo fornisce un'utile panoramica delle funzionalità coinvolte sia di base che più avanzate, trasmettendo la bellezza di npm.

Come per tutte le cose, esistono opinioni forti e si possono trovare molti difetti. Ma se non hai mai provato npm (o node, se è per questo), immergiti ed esploralo tu stesso. È probabile che ti divertirai più di quanto pensi.

Per articoli più interessanti su npm, prendi in considerazione la lettura di Using Scala.js con npm e Browserify.