npm-install

 npm install (senza args, in package dir) 
 npm install <name> 
 npm install <name><tag> 
 npm install <name><versione> 
 npm install <name>< gamma di versioni> 
 npm install <alias>@npm:< nome> 
 npm install <git-host><git-user><repo-nome> 
 npm install < url repogit> 
 npm install <tarball file> 
 npm install <tarball url> 
 npm install <folder> 
 alias: npm i, npm add 
 opzioni comuni: 

Descrizione

Questo comando installa un pacchetto e tutti i pacchetti da cui dipende. Se il pacchetto ha un file package-lock o shrinkwrap, l’installazione delle dipendenze sarà guidata da quello, con un npm-shrinkwrap.json che ha la precedenza se entrambi i file esistono. Vedere package-lock.json e npm shrinkwrap.

Un package è:

• a) una cartella contenente un programma descritto da un file package.json
• b) un tarball gzippato contenente (a)
• c) un url che risolve a (b)
• d) un <name>@<version> che è pubblicato sul registro (vedi registry) con (c)
• e) un <name>@<tag> (vedere npm dist-tag) che punta a (d)
• f) un <name> che ha un tag “latest” che soddisfa (e)
• g) un <git remote url> che si risolve in (a)

Anche se non pubblichi mai il tuo pacchetto, si possono ancora ottenere molti benefici dall’uso di npm se si vuole solo scrivere un programma su nodo (a), e forse se si vuole anche essere in grado di installarlo facilmente altrove dopo averlo impacchettato in un tarball (b).

• npm install (nella directory del pacchetto, senza argomenti):

  Installa le dipendenze nella cartella locale node_modules.

  In modalità globale (cioè con -g o --global aggiunto al comando), installa il contesto del pacchetto corrente (cioè la directory di lavoro corrente) come un pacchetto globale.

  Per default, npm install installerà tutti i moduli elencati come dipendenze in package.json.

  Con il flag --production (o quando la variabile d’ambiente NODE_ENV è impostata su production), npm non installa i moduli elencati indevDependencies. Per installare tutti i moduli elencati sia in dependencies che in devDependencies quando la variabile d’ambiente NODE_ENV è impostata su production, puoi usare --production=false.

  NOTA: Il flag --production non ha un significato particolare quando si aggiungono dipendenze a un progetto.

• npm install <folder>:

  Installa il pacchetto nella directory come symlink nel progetto corrente. Se <folder> si trova all’interno della radice del progetto, le sue dipendenze possono essere portate al livello superiore node_modules come farebbero per altri tipi di dipendenze.

• npm install <tarball file>:

  Installare un pacchetto che si trova sul filesystem. Nota: se vuoi solo collegare una directory dev alla tua root di npm, puoi farlo più facilmente usando npm link.

  Requisiti del tarball:

  • Il nome del file deve usare .tar.tar.gz, o .tgz come estensione.

  • Il contenuto del pacchetto dovrebbe risiedere in una sottocartella all’interno del tarball (di solito si chiama package/). npm rimuove un livello di directory durante l’installazione del pacchetto (viene eseguito un equivalente di tar x --strip-components=1).

  • Il pacchetto deve contenere un file package.json con proprietà name e version.

    Esempio:

    npm install ./package.tgz

• npm install <tarball url>:

  Recupera l’url del tarball e poi installalo. Per distinguere tra questa e le altre opzioni, l’argomento deve iniziare con “http://” o “https://”

  Esempio:

  npm install https://github.com/indexzero/forever/tarball/v0.5.6

• npm install <name>:

  Fate un’installazione <name>@<tag>, dove <tag> è la configurazione del “tag”. (Seeconfig. Il valore predefinito della configurazione è latest.)

  Nella maggior parte dei casi, questo installerà la versione dei moduli etichettati comelatest nel registro di npm.

  Esempio:

  npm install sax

• npm install <alias>@npm:<name>:

  Installa un pacchetto sotto un alias personalizzato. Permette versioni multiple di un pacchetto con lo stesso nome fianco a fianco, nomi di importazione più convenienti per pacchetti altrimenti lunghi e l’uso di sostituzioni git forks o pacchetti npm forked come sostituzioni. L’aliasing funziona solo sul tuo progetto e non rinomina i pacchetti nelle dipendenze transitive; gli alias dovrebbero seguire le convenzioni di denominazione indicate invalidate-npm-package-name.

  Esempi:

  npm install my-react@npm:react
   npm install jquery2@npm:jquery@2
   npm install jquery3@npm:jquery@3
   npm install npa@npm:npm-package-arg

 `npm install` salva qualsiasi pacchetto specificato in `dependencies` per impostazione predefinita.
Inoltre, è possibile controllare dove e come vengono salvati con alcuni
 flags aggiuntivi:
* `-P, --save-prod`: Il pacchetto apparirà nelle tue `dipendenze`. Questo è il
 default a meno che non siano presenti `-D` o `-O`.
* `-D, --save-dev`: Il pacchetto apparirà nelle tue `devDependencies`.
* `-O, --save-optional`: Il pacchetto apparirà nelle tue `optionalDependencies`. 
* `--no-save`: Impedisce il salvataggio nelle `dipendenze`.
Quando si usa una delle opzioni precedenti per salvare le dipendenze nel proprio
package.json, ci sono due flag aggiuntivi e opzionali:
* `-E, --save-exact`: Le dipendenze salvate saranno configurate con una
 versione esatta piuttosto che usare l'operatore predefinito di semver di npm
.
* `-B, --save-bundle`: Le dipendenze salvate saranno anche aggiunte alla tua lista `bundleDependencies`.
Inoltre, se hai un `npm-shrinkwrap.json` o `package-lock.json` allora anche questo
verrà aggiornato.
<scope>` è opzionale. Il pacchetto sarà scaricato dal registro
associato all'ambito specificato. Se nessun registro è associato a
l'ambito dato, viene assunto il registro predefinito. Vedere (/cli/v6/using-npm/scope).
Nota: se non si include il simbolo @ sul nome dello scope, npm lo
interpreterà invece come un repository GitHub, vedere sotto. I nomi degli scope
devono anche essere seguiti da una barra.
Esempi:
``bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-toccare -salva-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
```
**Nota**: Se c'è un file o una cartella chiamata `<nome>` nella directory corrente
lavoro, allora cercherà di installare quella, e cercherà solo di
 recuperare il pacchetto per nome se non è valido.

 npm install sax@"><0.2.0" supervisore di banco 

 npm install sax --force 

L’argomento --no-fund nasconderà il messaggio visualizzato alla fine di ogni installazione che riconosce il numero di dipendenze in cerca di finanziamento.Vedere npm-fund(1)

L’argomento -g o --global farà sì che npm installi il pacchetto a livello globale invece che locale. Vedi cartelle.

L’argomento --global-style farà sì che npm installi il pacchetto nella tua cartella locale node_modules con lo stesso layout che usa con la cartella node_modules globale. Solo le vostre dipendenze dirette appariranno innode_modules e tutto ciò da cui dipendono sarà appiattito nelle loronode_modules cartelle. Questo ovviamente eliminerà un po’ di deduping.

L’argomento --ignore-scripts farà sì che npm non esegua anyscripts definiti nel package.json. Vedi scripts.

L’argomento --legacy-bundling farà sì che npm installi il pacchetto in modo che le versioni di npm precedenti alla 1.4, come quella inclusa in node 0.8, possano installarlo. Questo elimina ogni deduplicazione automatica.

L’argomento --link farà sì che npm colleghi le installazioni globali nello spazio locale in alcuni casi.

L’argomento --no-bin-links impedirà a npm di creare collegamenti simbolici per qualsiasi binario che il pacchetto potrebbe contenere.

L’argomento --no-optional impedirà l’installazione delle dipendenze opzionali.

L’argomento --no-shrinkwrap, che ignorerà un blocco di pacchetto disponibile o un file shrinkwrap e userà il file package.json.

L’argomento --no-package-lock impedirà a npm di creare unpackage-lock.json file. Quando si esegue con il package-lock disabilitato npm non pota automaticamente i moduli di node durante l’installazione.

L’argomento --nodedir=/path/to/node/source permetterà a npm di trovare il codice sorgente di node in modo che npm possa compilare i moduli nativi.

L’argomento --only={prod|dev} farà sì che solodevDependencies o solo non-devDependencies venga installato indipendentemente dall’argomento NODE_ENV.

L’argomento --no-audit può essere usato per disabilitare l’invio di rapporti di audit ai registri configurati. Vedere npm-audit per i dettagli su cosa viene inviato.

Vedi config. Molti dei parametri di configurazione hanno qualche effetto sull’installazione, dato che è la maggior parte di ciò che fa npm.

Algoritmo

Per installare un pacchetto, npm usa il seguente algoritmo:

carica l'albero di node_modules esistente dal disco
clona l'albero
 recupera il pacchetto.json e metadati assortiti e aggiungerlo al clone 
 percorrere il clone e aggiungere eventuali dipendenze mancanti 
 le dipendenze saranno aggiunte il più vicino possibile alla cima 
 senza rompere nessun altro modulo
 confrontare l'albero originale con l'albero clonato e fare una lista di 
azioni da prendere per convertire uno nell'altro
eseguire tutte le azioni, i primi più profondi
 tipi di azioni sono installare, aggiornare, rimuovere e spostare

Per questa package{dep} struttura: A{B,C}, B{C}, C{D}, questo algoritmo produce:

 A
+-- B
+-- C
+-- D

Questo è, la dipendenza da B a C è soddisfatta dal fatto che A ha già causato l’installazione di C ad un livello superiore. D è ancora installato al livello più alto perché nulla è in conflitto con esso.

Per A{B,C}, B{C,D@1}, C{D@2}, questo algoritmo produce:

 A
+-- B
+-- C
 `-- D@2
+-- D@1

Perché il D@1 di B sarà installato nel livello superiore, C ora deve installare D@2 privatamente per se stesso. Questo algoritmo è deterministico, ma possono essere prodotti alberi diversi se due dipendenze sono richieste per l’installazione in un ordine diverso.

Vedi folders per una descrizione più dettagliata delle specifiche strutture di cartelle che npm crea.

Limitazioni dell’algoritmo di installazione di npm

npm rifiuta di installare qualsiasi pacchetto con un nome identico al pacchetto corrente. Questo può essere annullato con il flag --force, ma nella maggior parte dei casi può essere semplicemente affrontato cambiando il nome del pacchetto locale.

Ci sono alcuni casi limite molto rari e patologici in cui un ciclo può far sì che npm cerchi di installare un albero infinito di pacchetti. Ecco il caso più semplice:

 A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ... 

dove A è una qualche versione di un pacchetto, e A' è una versione diversa dello stesso pacchetto. Poiché B dipende da una versione diversa di A da quella che è già nell’albero, deve installare una copia separata. Lo stesso vale per A', che deve installare B'. Poiché B' dipende dalla versione originale di A, che è stata sovrascritta, il ciclo cade in un regresso infinito.

Per evitare questa situazione, npm rifiuta categoricamente di installare qualsiasiname@version che sia già presente da qualche parte nell’albero degli antenati di packagefolder. Una soluzione più corretta, ma più complessa, sarebbe quella di fare un link simbolico alla versione esistente nella nuova posizione. Se questo dovesse mai interessare un caso d’uso reale, sarà oggetto di indagine.

Vedi anche

• npm folders
• npm update
• npm audit
• npm fund
• npm link
• npm rebuild
• npm scripts
• npm build
• npm config
• npmrc
• npm registry
• npm dist-tag
• npm uninstall
• npm shrinkwrap
• package.json