npm-install

Synopsis

 npm install (met geen args, in package dir) 
 npm install <naam> 
 npm install <naam><tag> 
 npm install <naam><versie> 
 npm install <naam><versiebereik> 
 npm install <alias>@npm:<naam> 
 npm install <git-host><git-user><repo-naam> 
 npm install <git repo url> 
 npm install <tarball bestand> 
 npm install <tarball url> 
 npm install <map> 
 aliassen: npm i, npm add 
 gemeenschappelijke opties: 

Beschrijving

Deze opdracht installeert een pakket, en alle pakketten waarvan het afhankelijk is. Als het pakket een package-lock of shrinkwrap bestand heeft, zal de installatie van afhankelijkheden daardoor gestuurd worden, met een npm-shrinkwrap.json die voorrang heeft als beide bestanden bestaan. Zie package-lock.json en npm shrinkwrap.

Een package is:

• a) een map met een programma dat wordt beschreven door een package.json bestand
• b) een gzipped tarball die (a)
• c) een url die verwijst naar (b)
• d) een <name>@<version> die in het register is gepubliceerd (zie registry) met (c)
• e) een <name>@<tag> (zie ) die verwijst naar (d)
• f) een <name> die een “latest” tag heeft die voldoet aan (e)
• g) een <git remote url> die verwijst naar (a)

Zelfs als je je pakket nooit publiceert, kun je nog steeds veel voordelen halen uit het gebruik van npm als je gewoon een node programma wilt schrijven (a), en misschien als je het ook gemakkelijk elders wilt kunnen installeren nadat je het hebt ingepakt in een tarball (b).

• npm install (in package directory, geen argumenten):

  Installeer de dependencies in de lokale node_modules folder.

  In globale modus (d.w.z., met -g of --global toegevoegd aan het commando), installeert het de huidige pakket context (d.w.z., de huidige werkdirectory) als een globaal pakket.

  Standaard installeert npm install alle modules die als afhankelijkheden in package.json staan.

  Met de --production vlag (of wanneer de NODE_ENV omgevingsvariabele is ingesteld op production), zal npm geen modules installeren die indevDependencies staan. Om alle modules vermeld in zowel dependencies als devDependencies te installeren wanneer NODE_ENV omgevingsvariabele is ingesteld op production, kunt u --production=false gebruiken.

  Opmerking: De vlag --production heeft geen bijzondere betekenis bij het toevoegen van adependency aan een project.

• npm install <folder>:

  Installeer het pakket in de directory als een symlink in het huidige project. De afhankelijkheden worden geïnstalleerd voordat het wordt gekoppeld. Als <folder> in de root van uw project zit, kunnen de afhankelijkheden ervan naar hettoplevel node_modules worden getild, zoals dat bij andere soorten afhankelijkheden het geval zou zijn.

• npm install <tarball file>:

  Installeer een pakket dat op het bestandssysteem staat. Opmerking: als u alleen een dev directory in uw npm root wilt linken, kunt u dit eenvoudiger doen door npm link te gebruiken.

  Eisen aan de tarball:

  • In de bestandsnaam moet .tar.tar.gz, of .tgz worden gebruikt als extensie.

  • De inhoud van het pakket moet zich in een submap in de tarball bevinden (meestal heet deze package/). npm stript één maplaag bij het installeren van het pakket (een equivalent van tar x --strip-components=1 wordt uitgevoerd).

  • Het pakket moet een package.json bestand bevatten met name en version eigenschappen.

    Voorbeeld:

    npm install ./package.tgz

• npm install <tarball url>:

  Haal de tarball url op, en installeer deze vervolgens. Om onderscheid te maken tussen deze en andere opties, moet het argument beginnen met “http://” of “https://”

  Voorbeeld:

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

• npm install <name>:

  Doe een <name>@<tag> installatie, waarbij <tag> de “tag” config is. (Seeconfig. De standaardwaarde van de config is latest.)

  In de meeste gevallen zal dit de versie van de modules installeren die alslatest in het npm register staan.

  Voorbeeld:

  npm install sax

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

Installeer een pakket onder een aangepaste alias. Maakt meerdere versies van een pakket met dezelfde naam naast elkaar mogelijk, handigere importnamen voor pakketten met anders lange namen en het gebruik van vervangingen door git forks of gevorkte npm pakketten als vervangingen. Aliasing werkt alleen op uw project en hernoemt geen pakketten in transitieve afhankelijkheden. Aliassen moeten de naamgevingsconventies volgen zoals vermeld invalidate-npm-package-name.

Voorbeelden:

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` slaat standaard alle opgegeven pakketten op in `dependencies`.
Extra kunt u bepalen waar en hoe ze worden opgeslagen met enkele
additionele vlaggen:

* `-P, --save-prod`: Pakket zal verschijnen in uw `dependencies`. Dit is de
 standaard tenzij `-D` of `-O` aanwezig zijn.
* `-D, --save-dev`: Pakket zal verschijnen in uw `devDependencies`.
* `-O, --save-optional`: Pakket verschijnt in uw `optionalDependencies`.
* `--no-save`: Voorkomt opslaan in `dependencies`.
Wanneer u een van de bovenstaande opties gebruikt om dependencies op te slaan in uw
package.json, zijn er twee extra, optionele vlaggen:
* `-E, --save-exact`: Opgeslagen afhankelijkheden zullen worden geconfigureerd met een
 exacte versie in plaats van gebruik te maken van npm's standaard semver range
 operator.

* `-B, --save-bundle`: Opgeslagen afhankelijkheden worden ook toegevoegd aan uw `bundleDependencies` lijst.
Verder, als u een `npm-shrinkwrap.json` of `package-lock.json` hebt, dan
wordt deze ook bijgewerkt.
<scope>` is optioneel. Het pakket wordt gedownload van het register
 dat geassocieerd is met het opgegeven bereik. Als er geen register is gekoppeld aan
het opgegeven bereik wordt het standaardregister aangenomen. Zie (/cli/v6/using-npm/scope).
Note: als u het @-symbool niet toevoegt aan uw scopienaam, zal npm
 dit interpreteren als een GitHub-repository in plaats daarvan, zie hieronder. Scopes namen
moeten ook gevolgd worden door een schuine streep.
Voorbeelden:
``bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tik --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
``
**Note**: Als er een bestand of map met de naam `<naam>` in de huidige
werkdirectory staat, dan wordt geprobeerd die te installeren, en wordt alleen geprobeerd
het pakket op naam af te halen als deze niet geldig is.

• npm install <name>@<tag>:

  Installeer de versie van het pakket waarnaar wordt verwezen door de opgegeven tag.Als de tag niet bestaat in de registergegevens voor dat pakket, dan zal dit mislukken.

  Voorbeeld:

   npm install sax@latest 
   npm install @myorg/mypackage@latest 

• npm install <name>@<version>:

  Installeer de opgegeven versie van het pakket. Dit mislukt als de versie niet in het register is gepubliceerd.

  Voorbeeld:

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

• npm install <name>@<version range>:

  Installeer een versie van het pakket die overeenkomt met het opgegeven versiebereik. Dit volgt dezelfde regels voor het oplossen van afhankelijkheden als beschreven in package.json.

  Merk op dat de meeste versiebereiken tussen aanhalingstekens moeten worden gezet, zodat uw shell ze als een enkel argument zal behandelen.

  Voorbeeld:

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

• npm install <git remote url>:

  Installeert het pakket van de gehoste git provider, door het te klonen met git.Voor een volledige git remote url, zal alleen die URL geprobeerd worden.

  <protocol><hostname><path> 

  <protocol> is een van gitgit+sshgit+httpgit+https, ofgit+file.

  Als #<commit-ish> is meegegeven, zal het gebruikt worden om precies die commit te klonen. Als de commit-ish het formaat #semver:<semver> heeft, dan kan <semver> elk geldig semver bereik of exacte versie zijn, en npm zal zoeken naar alle tags of refs die overeenkomen met dat bereik in het remote repository, net zoals het zou doen voor een register afhankelijkheid. Als geen van beide #<commit-ish> of #semver:<semver> is gespecificeerd, dan wordt de standaard tak van de repository gebruikt.

  Als de repository gebruik maakt van submodules, dan zullen die submodules ook worden gekloond.

  Als het te installeren pakket een prepare script bevat, dan worden de dependencies en devDependencies daarvan geïnstalleerd, en wordt het preparescript uitgevoerd, voordat het pakket wordt ingepakt en geïnstalleerd.

  De volgende git omgevingsvariabelen worden door npm herkend en zullen aan de omgeving worden toegevoegd bij het uitvoeren van git:

  • GIT_ASKPASS

  • GIT_EXEC_PATH

  • GIT_PROXY_COMMAND

  • GIT_SSH

  • GIT_SSH_COMMAND

  • GIT_SSL_CAINFO

  • GIT_SSL_NO_VERIFY

    Zie de git man page voor meer informatie.

    Voorbeelden:

     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>:

  Installeer het pakket op https://github.com/githubname/githubrepo door te proberen het te klonen met git.

  Als #<commit-ish> is opgegeven, zal het gebruikt worden om precies die commit te clonen. Als de commit-ish het formaat #semver:<semver> heeft, dan kan <semver> elk geldig semver bereik of exacte versie zijn, en npm zal zoeken naar alle tags of refs die overeenkomen met dat bereik in het remote repository, net zoals het zou doen voor een register afhankelijkheid. Als #<commit-ish> of #semver:<semver> niet zijn gespecificeerd, dan wordt master gebruikt.

  Net als bij gewone git dependencies worden dependencies en devDependencies geinstalleerd als het pakket een prepare script heeft, voordat het pakket klaar is met installeren.

  Voorbeelden:

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

• npm install gist:<gistID>:

  Installeer het pakket op https://gist.github.com/gistID door te proberen het te klonen met git. De GitHub gebruikersnaam geassocieerd met de gist is optioneel en zal niet worden opgeslagen in package.json.

  Net als bij reguliere git dependencies, zullen dependencies en devDependencies geïnstalleerd worden als het pakket een prepare script heeft, voordat het pakket klaar is met installeren.

  Voorbeeld:

   npm install gist:

• npm install bitbucket:<bitbucketname>/<bitbucketrepo>:

  Installeer het pakket op https://bitbucket.org/bitbucketname/bitbucketrepo door te proberen het te klonen met git.

  Als #<commit-ish> is meegegeven, zal het gebruikt worden om precies die commit te clonen. Als de commit-ish het formaat #semver:<semver> heeft, dan kan <semver> elk geldig semver bereik of exacte versie zijn, en npm zal zoeken naar alle tags of refs die overeenkomen met dat bereik in het remote repository, net zoals het zou doen voor een register afhankelijkheid. Als #<commit-ish> of #semver:<semver> niet zijn gespecificeerd, dan wordt master gebruikt.

  Net als bij gewone git dependencies, dependencies en devDependencies worden geinstalleerd als het pakket een prepare script heeft, voordat het pakket klaar is met installeren.

  Voorbeeld:

   npm install bitbucket:mybitbucketuser/myproject 

• npm install gitlab:<gitlabname>/<gitlabrepo>:

  Installeer het pakket op https://gitlab.com/gitlabname/gitlabrepo door te proberen het te klonen met git.

  Als #<commit-ish> is meegegeven, zal het gebruikt worden om precies die commit te clonen. Als de commit-ish het formaat #semver:<semver> heeft, dan kan <semver> elk geldig semver bereik of exacte versie zijn, en npm zal zoeken naar alle tags of refs die overeenkomen met dat bereik in het remote repository, net zoals het zou doen voor een register afhankelijkheid. Als #<commit-ish> of #semver:<semver> niet zijn gespecificeerd, dan wordt master gebruikt.

  Net als bij gewone git dependencies, dependencies en devDependencies worden geinstalleerd als het pakket een prepare script heeft, voordat het pakket klaar is met installeren.

  Voorbeeld:

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

Je mag meerdere argumenten combineren, en zelfs meerdere soorten argumenten.Bijvoorbeeld:

 npm install sax@"><0.2.0" bank supervisor 

Het --tag argument zal van toepassing zijn op alle opgegeven installatiedoelen.

Het --dry-run argument rapporteert op de gebruikelijke manier wat de installatie zou hebben gedaan zonder daadwerkelijk iets te installeren.

Het --package-lock-only argument zal alleen de package-lock.json bijwerken, in plaats van node_modules te controleren en dependencies te downloaden.

Het -f of --force argument zal npm forceren om bronnen op afstand op te halen, zelfs als er al een lokale kopie op schijf bestaat.

 npm install sax --force 

Het --no-fund-argument verbergt de melding die aan het eind van elke installatie wordt weergegeven en die het aantal afhankelijkheden aangeeft dat op zoek is naar financiering.Zie npm-fund(1)

Het -g of --global argument zal ervoor zorgen dat npm het pakket globaal installeert in plaats van lokaal.

Het --global-style argument zorgt ervoor dat npm het pakket in uw lokale node_modules map installeert met dezelfde layout die het gebruikt met deglobale node_modules map. Enkel uw rechtstreekse afhankelijkheden zullen getoond worden innode_modules en alles waar ze van afhangen zal plat getoond worden in hunnode_modules folders. Dit zal uiteraard wat deduperen elimineren.

Het --ignore-scripts argument zal ervoor zorgen dat npm geen scripts uitvoert die gedefinieerd zijn in de package.json. Zie scripts.

Het --legacy-bundling argument zorgt ervoor dat npm het pakket zo installeert dat versies van npm van vóór 1.4, zoals de versie die met node 0.8 wordt meegeleverd, het pakket kunnen installeren. Dit elimineert alle automatische deduping.

Het --link argument zorgt ervoor dat npm in sommige gevallen globale installaties koppelt aan de lokale ruimte.

Het --no-bin-links argument zorgt ervoor dat npm geen symlinks aanmaakt voor alle binaries die het pakket kan bevatten.

Het --no-optional argument zal voorkomen dat optionele afhankelijkheden worden geïnstalleerd.

Het --no-shrinkwrap argument, dat een availablepackage lock of shrinkwrap bestand zal negeren en in plaats daarvan de package.json in plaats daarvan.

Het --no-package-lock argument zal voorkomen dat npm eenpackage-lock.json bestand aanmaakt. Als package-lock’s zijn uitgeschakeld, zal npm niet automatisch node-modules verwijderen tijdens de installatie.

Het --nodedir=/path/to/node/source argument zorgt ervoor dat npm de broncode van node kan vinden, zodat npm native modules kan compileren.

Het --only={prod|dev} argument zal ervoor zorgen dat ofwel alleendevDependencies of alleen nietdevDependencies worden geïnstalleerd, ongeacht de NODE_ENV.

Het --no-audit argument kan worden gebruikt om het versturen van audit rapporten naar de geconfigureerde registries uit te schakelen. Zie npm-audit voor details over wat wordt verzonden.

Zie config. Veel van de configuratieparameters hebben een effect op de installatie, omdat dat het meeste is wat npm doet.

Algoritme

Om een pakket te installeren, gebruikt npm het volgende algoritme:

laad de bestaande node_modules-boom van schijf
kloon de boom
 haal het pakket op.json en geassorteerde metadata op en voeg deze toe aan de kloon 
 doorloop de kloon en voeg eventuele ontbrekende afhankelijkheden toe 
 afhankelijkheden worden zo dicht mogelijk bij de top toegevoegd 
 zonder andere modules te breken
 vergelijk de originele boom met de gekloonde boom en maak een lijst van 
acties die moeten worden ondernomen om de ene naar de andere om te zetten
 voer alle acties uit, de diepste eerste
 soorten acties zijn installeren, bijwerken, verwijderen en verplaatsen

Voor dezepackage{dep}structuur:A{B,C}, B{C}, C{D}, produceert dit algoritme:

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

Dat wil zeggen, aan de afhankelijkheid van B naar C wordt voldaan door het feit dat Aal er al voor heeft gezorgd dat C op een hoger niveau is geïnstalleerd. D wordt nog steeds op het hoogste niveau geïnstalleerd omdat er niets mee in strijd is.

Voor A{B,C}, B{C,D@1}, C{D@2}, levert dit algoritme op:

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

Omdat B’s D@1 op het hoogste niveau zal worden geïnstalleerd, moet C nu D@2privé voor zichzelf installeren. Dit algoritme is deterministisch, maar er kunnen verschillende bomen ontstaan als twee dependencies in een andere volgorde worden aangevraagd voor installatie.

Zie mappen voor een meer gedetailleerde beschrijving van de specifieke mapstructuren die npm aanmaakt.

Beperkingen van npm’s installatiealgoritme

npm zal weigeren elk pakket te installeren met een identieke naam aan het huidige pakket. Dit kan worden opgeheven met de --force vlag, maar in de meeste gevallen kan dit eenvoudig worden opgelost door de lokale pakketnaam te veranderen.

Er zijn enkele zeldzame en pathologische randgevallen waarbij een cyclus ervoor zorgt dat npm een oneindige boom van pakketten probeert te installeren. Hier is het eenvoudigste geval:

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

waar A een versie van een pakket is, en A' een andere versie van hetzelfde pakket is. Omdat B afhankelijk is van een andere versie van A dan de versie die al in de boom zit, moet het een aparte kopie installeren. Hetzelfde geldt voor A', die B' moet installeren. Omdat B' afhankelijk is van de oorspronkelijke versie van A, die is overschreven, valt de cyclus in oneindige regress.

Om deze situatie te vermijden, weigert npm botweg om eenname@version te installeren die al ergens in de boom van packagefolder voorouders aanwezig is. Een meer correcte, maar complexere, oplossing zou zijn om de bestaande versie te symlinken naar de nieuwe locatie. Als dit ooit een echte use-case raakt, zal het worden onderzocht.

See Also

• 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