npm-install

`npm install`enregistre tout paquet spécifié dans `dependencies` par défaut.
En outre, vous pouvez contrôler où et comment ils sont enregistrés avec quelques
flags supplémentaires :
* `-P, --save-prod` : Le paquet apparaîtra dans vos `dépendances`. C'est le
 défaut sauf si `-D` ou `-O` sont présents.
* `-D, --save-dev` : Le paquet apparaîtra dans vos `devDependencies`.
* `-O, --save-optional` : Le paquet apparaîtra dans vos `optionalDependencies`.
* `--no-save` : Empêche l'enregistrement dans les `dépendances`.
Lorsque vous utilisez l'une des options ci-dessus pour enregistrer les dépendances dans votre
package.json, il existe deux drapeaux supplémentaires et facultatifs :
* `-E, --save-exact` : Les dépendances sauvegardées seront configurées avec une
 version exacte plutôt que d'utiliser l'opérateur semver range
* `-B, --save-bundle` : Les dépendances enregistrées seront également ajoutées à votre liste `bundleDependencies`.
De plus, si vous avez un `npm-shrinkwrap.json` ou un `package-lock.json` alors il
seront également mis à jour.
<scope>` est facultatif. Le paquet sera téléchargé à partir du registre
associé à la portée spécifiée. Si aucun registre n'est associé à
la portée donnée, le registre par défaut est supposé. Voir (/cli/v6/using-npm/scope).
Note : si vous n'incluez pas le symbole @ sur votre nom de scope, npm va
interpréter cela comme un dépôt GitHub à la place, voir ci-dessous. Les noms des scopes
doivent également être suivis d'une barre oblique.
Exemples :
``bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tap --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
``
**Note** : S'il existe un fichier ou un dossier nommé `<nom>` dans le répertoire de
travail actuel, alors il essaiera de l'installer, et n'essaiera de
rechercher le paquet par son nom que si celui-ci n'est pas valide.
 
 
 
 
npm install <name>@<tag>:
 
Installer la version du paquet qui est référencée par le tag spécifié.Si la balise n'existe pas dans les données du registre pour ce paquet, alors cette opération échouera.
 
Exemple :
 
 
 npm install sax@latest 
 npm install @myorg/mypackage@latest 


npm install <name>@<version> :
Installer la version spécifiée du paquet. Cette opération échouera si la version n'a pas été publiée dans le registre.
Exemple :

 npm install [email protected] 
 npm install @myorg/[email protected] 

npm install <name>@<version range> :
Installer une version du paquet correspondant à la plage de versions spécifiée. Cela suivra les mêmes règles de résolution des dépendances décrites dans package.json.
Notez que la plupart des plages de versions doivent être mises entre guillemets afin que votre shell les traite comme un seul argument.
Exemple:

 npm install sax@"><0.2.0" 
 npm install @myorg/privatepackage@"><0.2.0" 


npm install <git remote url>:
Installe le paquet depuis le fournisseur git hébergé, en le clonant avec git.Pour une url distante git complète, seule cette url sera tentée.

<protocole><hostname><path> 

<protocol> est un des gitgit+sshgit+httpgit+https, ougit+file.
Si #<commit-ish> est fourni, il sera utilisé pour cloner exactement cecommit. Si le commit-ish a le format #semver:<semver><semver> peut être n'importe quelle plage de semver valide ou version exacte, et npm cherchera tous les tagsou refs correspondant à cette plage dans le dépôt distant, un peu comme il le ferait pour une dépendance de registre. Si ni #<commit-ish> ni #semver:<semver> isspecified, alors la branche par défaut du dépôt est utilisée.
Si le dépôt fait usage de submodules, ces submodules seront clonés également.
Si le paquet en cours d'installation contient un prepare script, ses dependencies et devDependencies seront installés, et le preparescript sera exécuté, avant que le paquet ne soit empaqueté et installé.
Les variables d'environnement git suivantes sont reconnues par npm et seront ajoutées à l'environnement lors de l'exécution de git :


GIT_ASKPASS


GIT_EXEC_PATH


GIT_PROXY_COMMAND


GIT_SSH

. 

GIT_SSH_COMMAND


GIT_SSL_CAINFO


GIT_SSL_NO_VERIFY
Voir la page de manuel git pour plus de détails.
Exemples:

 npm install git+ssh://[email protected]:npm/cli.git#v1.0.27 
 npm install git+ssh://[email protected]:npm/cli#semver:^5.0 
 npm install git+https://[email protected]/npm/cli.git 
 npm install git://github.com/npm/cli.git#v1.0.27 
 GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://[email protected]:npm/cli.git 





npm install <githubname>/<githubrepo> :


npm install github:<githubname>/<githubrepo>:
Installer le paquet à https://github.com/githubname/githubrepo en tentant de le cloner à l'aide de git.
Si #<commit-ish> est fourni, il sera utilisé pour cloner exactement cecommit. Si le commit-ish a le format #semver:<semver><semver> peut être n'importe quelle plage de semver valide ou version exacte, et npm cherchera tous les tagsou refs correspondant à cette plage dans le dépôt distant, un peu comme il le ferait pour une dépendance de registre. Si ni #<commit-ish> ni #semver:<semver> ne sont spécifiés, alors master est utilisé.
Comme pour les dépendances git régulières, dependencies et devDependencies seront installés si le paquet a un script prepare, avant que le paquet ne soit terminé d'installer.
Exemples:

 npm install mygithubuser/myproject 
 npm install github :mygithubuser/myproject 



npm install gist:<gistID>:
Installer le paquet à https://gist.github.com/gistID en tentant de le cloner à l'aide de git. Le nom d'utilisateur GitHub associé au gist estoptionnel et ne sera pas enregistré dans package.json.
Comme pour les dépendances git régulières, dependencies et devDependencies seront installés si le paquet a un script prepare, avant que le paquet ne soit terminé d'installer.
Exemple:

 npm install gist:



npm install bitbucket:<bitbucketname>/<bitbucketrepo> :
Installer le paquet à https://bitbucket.org/bitbucketname/bitbucketrepoen tentant de le cloner à l'aide de git.
Si #<commit-ish> est fourni, il sera utilisé pour cloner exactement cecommit. Si le commit-ish a le format #semver:<semver><semver> peut être n'importe quelle plage de semver valide ou version exacte, et npm cherchera tous les tagsou refs correspondant à cette plage dans le dépôt distant, un peu comme il le ferait pour une dépendance de registre. Si ni #<commit-ish> ni #semver:<semver> ne sont spécifiés, alors master est utilisé.
Comme pour les dépendances git ordinaires, dependencies et devDependencies seront installés si le paquet a un script prepare, avant que le paquet ne soit terminé d'installer.
Exemple:

 npm install bitbucket:mybitbucketuser/myproject 



npm install gitlab:<gitlabname>/<gitlabrepo> :
Installer le paquet à https://gitlab.com/gitlabname/gitlabrepoen tentant de le cloner à l'aide de git.
Si #<commit-ish> est fourni, il sera utilisé pour cloner exactement cecommit. Si le commit-ish a le format #semver:<semver><semver> peut être n'importe quelle plage de semver valide ou version exacte, et npm cherchera tous les tagsou refs correspondant à cette plage dans le dépôt distant, un peu comme il le ferait pour une dépendance de registre. Si ni #<commit-ish> ni #semver:<semver> ne sont spécifiés, alors master est utilisé.
Comme pour les dépendances git ordinaires, dependencies et devDependencies seront installés si le paquet a un script prepare, avant que le paquet ne soit terminé d'installer.
Exemple:

 npm install gitlab:mygitlabuser/myproject 
 npm install gitlab:myusr/myproj#semver:^5.0 



Vous pouvez combiner plusieurs arguments, et même plusieurs types d'arguments.Par exemple:

 npm install sax@"><0.2.0" bench supervisor 

L'argument --tag s'appliquera à toutes les cibles d'installation spécifiées. Si atag avec le nom donné existe, la version étiquetée est préférée aux nouvelles versions.
L'argument --dry-run rapportera de manière habituelle ce que l'installation aurait fait sans réellement installer quoi que ce soit.
L'argument --package-lock-only mettra uniquement à jour la package-lock.json,au lieu de vérifier node_modules et de télécharger les dépendances.
L'argument -f ou --force forcera npm à aller chercher des ressources distantes même si une copie locale existe sur le disque.

 npm install sax --force 

L'argument --no-fund masquera le message affiché à la fin de chaqueinstallation qui reconnaît le nombre de dépendances à la recherche de financement.Voir npm-fund(1)
L'argument -g ou --global fera en sorte que npm installe le paquet globalement plutôt que localement. Voir dossiers.
L'argument --global-style fera en sorte que npm installe le paquet dansvotre dossier local node_modules avec la même disposition qu'il utilise avec le dossierglobal node_modules. Seules vos dépendances directes apparaîtront dansnode_modules et tout ce dont elles dépendent sera aplati dans leurs dossiersnode_modules. Cela éliminera évidemment certains dédoublements.
L'argument --ignore-scripts fera en sorte que npm n'exécute pas les anyscripts définis dans le package.json. Voir scripts.
L'argument --legacy-bundling fera en sorte que npm installe le paquet de telle sorte que les versions de npm antérieures à 1.4, comme celle incluse avec node 0.8, puissent installer le paquet. Cela élimine tout dédoublement automatique.
L'argument --link fera en sorte que npm lie les installations globales dans l'espace local dans certains cas.
L'argument --no-bin-links empêchera npm de créer des liens symboliques pour toutes les binaires que le paquet pourrait contenir.
L'argument --no-optional empêchera les dépendances optionnelles d'être installées.
L'argument --no-shrinkwrap, qui ignorera un verrou de package disponible ou un fichier shrinkwrap et utilisera le package.json à la place.
L'argument --no-package-lock empêchera npm de créer un fichierpackage-lock.json. Lors de l'exécution avec la désactivation de package-lock, npm n'élaguera pas automatiquement vos modules node lors de l'installation.
L'argument --nodedir=/path/to/node/source permettra à npm de trouver le code source de thenode afin que npm puisse compiler les modules natifs.
L'argument --only={prod|dev} entraînera l'installation de seulementdevDependencies ou de seulement non-devDependencies indépendamment du NODE_ENV.
L'argument --no-audit peut être utilisé pour désactiver l'envoi de rapports d'audit aux registres configurés. Voir npm-audit pour des détails sur ce qui est envoyé.
Voir config. Beaucoup des paramètres de configuration ont un certain effet sur l'installation, puisque c'est la plupart de ce que fait npm.
Algorithme
Pour installer un paquet, npm utilise l'algorithme suivant :

load the existing node_modules tree from disk
clone the tree
 fetch the package.json et les métadonnées assorties et l'ajouter au clone
 parcourir le clone et ajouter toutes les dépendances manquantes
 les dépendances seront ajoutées aussi près du sommet que possible
. sans casser d'autres modules
 comparer l'arbre original avec l'arbre cloné et faire une liste des 
actions à entreprendre pour convertir l'un en l'autre
exécuter toutes les actions, les premières
 sortes d'actions les plus profondes sont installer, mettre à jour, supprimer et déplacer

Pour cette package{dep} structure : A{B,C}, B{C}, C{D}, cet algorithme produit :

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

C'est-à-dire , la dépendance de B vers C est satisfaite par le fait que Aa déjà provoqué l'installation de C à un niveau supérieur. D est toujours installé au niveau supérieur car rien n'entre en conflit avec lui.
Pour A{B,C}, B{C,D@1}, C{D@2}, cet algorithme produit :

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

Parce que le D@1 de B sera installé au niveau supérieur, C doit maintenant installer D@2privément pour lui-même. Cet algorithme est déterministe, mais des arbres différents peut-être produits si deux dépendances sont demandées pour une installation dans un ordre différent.
Voir folders pour une description plus détaillée des structures de dossiers spécifiques que npm crée.
Limites de l'algorithme d'installation de npm
npm refusera d'installer tout paquet ayant un nom identique au paquetcurrent. Ceci peut être surchargé avec le drapeau --force, mais dans la plupart des cas, on peut simplement y remédier en changeant le nom du paquet local.
Il existe quelques cas limites très rares et pathologiques où un cycle peutcause npm d'essayer d'installer un arbre interminable de paquets. Voici le cas le plus simple :

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

où A est une certaine version d'un paquet, et A' est une version différente du même paquet. Parce que B dépend d'une version de A différente de celle qui est déjà dans l'arbre, il doit installer une copie séparée. Il en va de même pour A', qui doit installer B'. Comme B' dépend de la version originale de A, qui a été surchargée, le cycle tombe dans une régression infinie.
Pour éviter cette situation, npm refuse carrément d'installer toutname@version qui est déjà présent n'importe où dans l'arbre des ancêtres du packagefolder. Une solution plus correcte, mais plus complexe, consisterait à établir un lien symbolique entre la version existante et le nouvel emplacement. Si cela affecte un jour un cas d'utilisation réel, il sera étudié.
Voir aussi

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