npm-install

Synopsis

 npm install (mit no args, im Paketverzeichnis) 
 npm install <name> 
 npm install <name><tag> 
 npm install <name><version> 
 npm install <name><Versionsbereich> 
 npm install <alias>@npm:<name> 
 npm install <git-host><git-user><repo-name> 
 npm install <git repo url> 
 npm install <tarball file> 
 npm install <tarball url> 
 npm install <folder> 
 aliases: npm i, npm add 
 gemeinsame Optionen: 

Beschreibung

Dieser Befehl installiert ein Paket und alle Pakete, von denen es abhängt. Wenn das Paket eine Package-Lock- oder Shrinkwrap-Datei hat, wird die Installation der Abhängigkeiten durch diese gesteuert, wobei ein npm-shrinkwrap.json Vorrang hat, wenn beide Dateien existieren. Siehe package-lock.json und npm shrinkwrap.

Ein package ist:

• a) ein Ordner, der ein Programm enthält, das durch eine package.json-Datei beschrieben wird
• b) ein gzipped tarball, der (a)
• c) eine Url, die zu (b)
• d) ein <name>@<version>, das in der Registry veröffentlicht ist (siehe registry) mit (c)
• e) ein <name>@<tag> (siehe npm dist-tag), das auf (d)
• f) ein <name> zeigt, das ein „latest“-Tag hat, das (e)
• g) ein <git remote url>, das auf (a)

Auch wenn Sie Ihr Paket nie veröffentlichen, können Sie immer noch viele Vorteile aus der Verwendung von npm ziehen, wenn Sie einfach nur ein Node-Programm schreiben wollen (a), und vielleicht auch, wenn Sie in der Lage sein wollen, es einfach an anderer Stelle zu installieren, nachdem Sie es in einen Tarball gepackt haben (b).

• npm install (im Paketverzeichnis, keine Argumente):

  Installieren Sie die Abhängigkeiten im lokalen Ordner node_modules.

  Im globalen Modus (d.h. mit -g oder --global an den Befehl angehängt) wird der aktuelle Paketkontext (also das aktuelle Arbeitsverzeichnis) als globales Paket installiert.

  Standardmäßig installiert npm install alle Module, die als Abhängigkeiten in package.json aufgeführt sind.

  Mit dem Flag --production (oder wenn die Umgebungsvariable NODE_ENV auf production gesetzt ist), installiert npm keine Module, die in devDependencies aufgeführt sind. Um alle Module zu installieren, die sowohl in dependenciesals auch in devDependencies aufgeführt sind, wenn die NODE_ENV-Umgebungsvariable auf production gesetzt ist, können Sie --production=false verwenden.

  Hinweis: Das --production-Flag hat keine besondere Bedeutung beim Hinzufügen von Adependency zu einem Projekt.

• npm install <folder>:

  Installieren Sie das Paket im Verzeichnis als Symlink in das aktuelle Projekt, seine Abhängigkeiten werden installiert, bevor es gelinkt wird. Wenn <folder> im Wurzelverzeichnis Ihres Projekts liegt, können seine Abhängigkeiten auf die oberste Ebene node_modules gehievt werden, wie es bei anderen Arten von Abhängigkeiten der Fall wäre.

• npm install <tarball file>:

  Installieren Sie ein Paket, das sich auf dem Dateisystem befindet. Hinweis: Wenn Sie nur ein Dev-Verzeichnis in Ihr npm-Root einbinden wollen, können Sie dies einfacher mit npm link tun.

  Anforderungen an den Tarball:

  • Der Dateiname muss .tar.tar.gz oder .tgz als Erweiterung verwenden.

  • Der Inhalt des Pakets sollte sich in einem Unterordner innerhalb des Tarballs befinden (normalerweise heißt er package/). npm entfernt bei der Installation des Pakets eine Verzeichnisebene (es wird ein Äquivalent von tar x --strip-components=1 ausgeführt).

  • Das Paket muss eine package.json-Datei mit den Eigenschaften name und version enthalten.

    Beispiel:

    npm install ./package.tgz

• npm install <tarball url>:

  Holen Sie sich die Url des Tarballs und installieren Sie ihn dann. Um diese Option von anderen Optionen zu unterscheiden, muss das Argument mit „http://“ oder „https://“ beginnen.

  Beispiel:

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

• npm install <name>:

  Installieren Sie ein <name>@<tag>, wobei <tag> die „Tag“-Konfiguration ist. (Seeconfig. Der Standardwert der Config ist latest.)

  In den meisten Fällen wird dadurch die Version der Module installiert, die in der npm-Registry alslatest gekennzeichnet ist.

  Beispiel:

  npm install sax

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

  Installieren Sie ein Paket unter einem eigenen Alias. Ermöglicht mehrere Versionen eines gleichnamigen Pakets nebeneinander, bequemere Importnamen für Pakete mit ansonsten langen Namen und die Verwendung von Git-Forks als Ersatz oder von geforkten npm-Paketen als Ersatz. Aliasing funktioniert nur in Ihrem Projekt und benennt Pakete in transitiven Abhängigkeiten nicht um.Aliase sollten den invalidate-npm-package-name angegebenen Namenskonventionen folgen.

  Beispiele:

  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` speichert standardmäßig alle angegebenen Pakete in `dependencies`.
Zusätzlich können Sie mit einigen
zusätzlichen Flags steuern, wo und wie sie gespeichert werden:
* `-P, --save-prod`: Das Paket wird in Ihren `Abhängigkeiten` erscheinen. Dies ist der
 Standard, es sei denn, `-D` oder `-O` sind vorhanden.
* `-D, --save-dev`: Das Paket wird in Ihren `devDependencies` erscheinen.
* `-O, --save-optional`: Das Paket erscheint in den `optionalDependencies`.
* `--no-save`: Verhindert das Speichern in `Abhängigkeiten`.
Wenn Sie eine der obigen Optionen zum Speichern von Abhängigkeiten in Ihrer
Package.json, gibt es zwei zusätzliche, optionale Flags:
* `-E, --save-exact`: Gespeicherte Abhängigkeiten werden mit einer
 exakten Version konfiguriert, anstatt den Standard-Semver-Range
-Operator von npm zu verwenden.
* `-B, --save-bundle`: Gespeicherte Abhängigkeiten werden auch zu Ihrer `bundleDependencies`-Liste hinzugefügt.
Weiterhin, wenn Sie eine `npm-shrinkwrap.json` oder `package-lock.json` dann
wird diese ebenfalls aktualisiert.

• npm install <name>@<tag>:

  Installieren Sie die Version des Pakets, auf die das angegebene Tag verweist.Wenn das Tag nicht in den Registrierungsdaten für dieses Paket vorhanden ist, schlägt dies fehl.

  Beispiel:

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

• npm install <name>@<version>:

  Installieren Sie die angegebene Version des Pakets. Dies schlägt fehl, wenn die Version nicht in der Registry veröffentlicht wurde.

  Beispiel:

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

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

  Installieren Sie eine Version des Pakets, die in den angegebenen Versionsbereich passt. Dabei gelten die gleichen Regeln für das Auflösen von Abhängigkeiten wie unter package.json beschrieben.

  Beachten Sie, dass die meisten Versionsbereiche in Anführungszeichen gesetzt werden müssen, damit Ihre Shell sie als ein einzelnes Argument behandelt.

  Beispiel:

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

• npm install <git remote url>:

  Installiert das Paket vom gehosteten Git-Provider und klont es mit git.Bei einer vollständigen Git-Remote-URL wird nur diese URL ausprobiert.

  <protocol><hostname><path> 

  <protocol> ist eine von gitgit+sshgit+httpgit+https, odergit+file.

  Wenn #<commit-ish> angegeben wird, wird es verwendet, um genau diesen Commit zu klonen. Wenn der Commit-ish das Format #semver:<semver> hat, kann <semver> ein beliebiger gültiger Semver-Bereich oder eine exakte Version sein, und npm sucht im entfernten Repository nach allen Tags oder Refs, die zu diesem Bereich passen, ähnlich wie es bei einer Gistry-Abhängigkeit der Fall wäre. Wenn weder #<commit-ish> noch #semver:<semver> angegeben ist, wird der Standardzweig des Repositorys verwendet.

  Wenn das Repository Submodule verwendet, werden diese ebenfalls geklont.

  Wenn das zu installierende Paket ein prepare-Skript enthält, werden dessendependencies und devDependencies installiert und das preparescript ausgeführt, bevor das Paket gepackt und installiert wird.

  Die folgenden Git-Umgebungsvariablen werden von npm erkannt und beim Ausführen von Git zur Umgebung hinzugefügt:

  • GIT_ASKPASS

  • GIT_EXEC_PATH

  • GIT_PROXY_COMMAND

  • GIT_SSH

  • GIT_SSH_COMMAND

  • GIT_SSL_CAINFO

  • GIT_SSL_NO_VERIFY

    Siehe die git man page für Details.

    Beispiele:

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

  Installieren Sie das Paket unter https://github.com/githubname/githubrepo, indem Sie versuchen, es mit git zu klonen.

  Wenn #<commit-ish> angegeben wird, wird es verwendet, um genau diesen Commit zu klonen. Wenn der Commit-ish das Format #semver:<semver> hat, kann <semver> ein beliebiger gültiger Semver-Bereich oder eine exakte Version sein, und npm sucht im entfernten Repository nach allen Tags oder Refs, die zu diesem Bereich passen, ähnlich wie es bei einer Gistry-Abhängigkeit der Fall wäre. Wenn weder #<commit-ish> noch #semver:<semver> angegeben wird, dann wird master verwendet.

  Wie bei regulären Git-Abhängigkeiten werden dependencies und devDependencies installiert, wenn das Paket ein prepare-Skript hat, bevor das Paket fertig installiert ist.

  Beispiele:

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

• npm install gist:<gistID>:

  Installieren Sie das Paket unter https://gist.github.com/gistID, indem Sie versuchen, es mit git zu klonen. Der mit dem Gist verbundene GitHub-Benutzername ist optional und wird nicht in package.json gespeichert.

  Wie bei regulären Git-Abhängigkeiten werden dependencies und devDependencies installiert, wenn das Paket ein prepare-Skript hat, bevor das Paket fertig installiert ist.

  Beispiel:

   npm install gist:

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

  Installieren Sie das Paket unter https://bitbucket.org/bitbucketname/bitbucketrepo, indem Sie versuchen, es mit git zu klonen.

  Wenn #<commit-ish> angegeben ist, wird es verwendet, um genau diesen Commit zu klonen. Wenn der Commit-ish das Format #semver:<semver> hat, kann <semver> ein beliebiger gültiger Semver-Bereich oder eine exakte Version sein, und npm sucht im entfernten Repository nach allen Tags oder Refs, die zu diesem Bereich passen, ähnlich wie es bei einer Gistry-Abhängigkeit der Fall wäre. Wenn weder #<commit-ish> noch #semver:<semver> angegeben wird, dann wird master verwendet.

  Wie bei regulären Git-Abhängigkeiten werden dependencies und devDependencies installiert, wenn das Paket ein prepare Skript hat, bevor das Paket fertig installiert ist.

  Beispiel:

   npm install bitbucket:mybitbucketuser/myproject 

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

  Installieren Sie das Paket unter https://gitlab.com/gitlabname/gitlabrepo, indem Sie versuchen, es mit git zu klonen.

  Wenn #<commit-ish> angegeben ist, wird es verwendet, um genau diesen Commit zu klonen. Wenn der Commit-ish das Format #semver:<semver> hat, kann <semver> ein beliebiger gültiger Semver-Bereich oder eine exakte Version sein, und npm sucht im entfernten Repository nach allen Tags oder Refs, die zu diesem Bereich passen, ähnlich wie es bei einer Gistry-Abhängigkeit der Fall wäre. Wenn weder #<commit-ish> noch #semver:<semver> angegeben wird, dann wird master verwendet.

  Wie bei regulären Git-Abhängigkeiten werden dependencies und devDependencies installiert, wenn das Paket ein prepare Skript hat, bevor das Paket fertig installiert ist.

  Beispiel:

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

Sie können mehrere Argumente und sogar mehrere Arten von Argumenten kombinieren.Zum Beispiel:

 npm install sax@"><0.2.0" bench supervisor 

Das Argument --tag gilt für alle angegebenen Installationsziele. Wenn atag mit dem angegebenen Namen existiert, wird die markierte Version gegenüber neuen Versionen bevorzugt.

Das --dry-run-Argument meldet auf die übliche Weise, was die Installation getan hätte, ohne tatsächlich etwas zu installieren.

Das --package-lock-only-Argument wird nur das package-lock.json aktualisieren, anstatt das node_modules zu überprüfen und Abhängigkeiten herunterzuladen.

Das Argument -f oder --force zwingt npm, entfernte Ressourcen zu holen, auch wenn eine lokale Kopie auf der Platte existiert.

 npm install sax --force 

Das --no-fund-Argument blendet die Meldung aus, die am Ende jeder Installation angezeigt wird und die Anzahl der Abhängigkeiten bestätigt, die nach Mitteln suchen.Siehe npm-fund(1)

Das -g oder --global Argument veranlasst npm, das Paket global statt lokal zu installieren. Siehe Ordner.

Das --global-style-Argument veranlasst npm, das Paket in Ihren lokalen node_modules-Ordner mit demselben Layout zu installieren, das es für den globalen node_modules-Ordner verwendet. Nur Ihre direkten Abhängigkeiten werden innode_modules angezeigt und alles, wovon sie abhängen, wird in ihrennode_modules-Ordnern abgeflacht. Dadurch wird natürlich etwas Deduping vermieden.

Das --ignore-scripts-Argument bewirkt, dass npm keine in der package.json definierten Skripte ausführt. Siehe scripts.

Das --legacy-bundling-Argument veranlasst npm, das Paket so zu installieren, dass Versionen von npm vor 1.4, wie die in Node 0.8 enthaltene, das Paket installieren können. Dadurch wird das automatische Deduping eliminiert.

Das --link-Argument veranlasst npm in einigen Fällen, globale Installationen in den lokalen Bereich zu verlinken.

Das --no-bin-links-Argument verhindert, dass npm Symlinks für beliebige Binärdateien, die das Paket enthalten könnte, erstellt.

Das --no-optional-Argument verhindert, dass optionale Abhängigkeiten installiert werden.

Das --no-shrinkwrap-Argument, das eine verfügbare Paketsperre oder Shrinkwrap-Datei ignoriert und stattdessen die package.json stattdessen verwendet.

Das --no-package-lock-Argument verhindert, dass npm einepackage-lock.json-Datei erstellt. Wenn Sie mit deaktivierten Paket-Locks arbeiten, wird npm Ihre Node-Module bei der Installation nicht automatisch beschneiden.

Das --nodedir=/path/to/node/source-Argument ermöglicht npm, den Node-Quellcode zu finden, damit npm native Module kompilieren kann.

Das --only={prod|dev}-Argument bewirkt, dass entweder nurdevDependencies oder nur Nicht-devDependencies installiert werden, unabhängig vom NODE_ENV.

Das --no-audit-Argument kann verwendet werden, um das Senden von Audit-Berichten an die konfigurierten Registraturen zu deaktivieren. Siehe npm-audit für Details darüber, was gesendet wird.

Siehe config. Viele der Konfigurationsparameter haben eine Auswirkung auf die Installation, da dies das meiste ist, was npm macht.

Algorithmus

Um ein Paket zu installieren, verwendet npm den folgenden Algorithmus:

Laden Sie den bestehenden node_modules-Baum von der Festplatte
Klonen Sie den Baum
 Holen Sie das Paket.json und verschiedene Metadaten und fügen Sie es dem Klon hinzu 
 Gehen Sie durch den Klon und fügen Sie alle fehlenden Abhängigkeiten hinzu 
 Abhängigkeiten werden so nah wie möglich an der Spitze hinzugefügt 
 ohne andere Module zu zerstören
 Vergleichen Sie den ursprünglichen Baum mit dem geklonten Baum und erstellen Sie eine Liste von 
Aktionen, die Sie durchführen müssen, um den einen in den anderen umzuwandeln
Ausführen aller Aktionen, Die tiefsten
 Arten von Aktionen sind Installieren, Aktualisieren, Entfernen und Verschieben

Für diese package{dep} Struktur: A{B,C}, B{C}, C{D},erzeugt dieser Algorithmus:

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

Das heißt, die Abhängigkeit von B zu C wird dadurch erfüllt, dass A bereits bewirkt hat, dass C auf einer höheren Ebene installiert wird. D wird immer noch auf der obersten Ebene installiert, weil nichts mit ihm kollidiert.

Für A{B,C}, B{C,D@1}, C{D@2} ergibt dieser Algorithmus:

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

Denn B’s D@1 wird in der obersten Ebene installiert, muss C nun D@2privat für sich selbst installieren. Dieser Algorithmus ist deterministisch, aber es können unterschiedliche Bäume erzeugt werden, wenn zwei Abhängigkeiten in unterschiedlicher Reihenfolge zur Installation angefordert werden.

Eine genauere Beschreibung der spezifischen Ordnerstrukturen, die npm erzeugt, finden Sie unter folders.

Einschränkungen des npm-Installationsalgorithmus

npm verweigert die Installation von Paketen, die einen identischen Namen wie das aktuelle Paket haben. Dies kann mit dem --force-Flag überschrieben werden, aber in den meisten Fällen kann dies einfach durch Ändern des lokalen Paketnamens behoben werden.

Es gibt einige sehr seltene und pathologische Randfälle, in denen ein Zyklus dazu führt, dass npm versucht, einen nicht enden wollenden Baum von Paketen zu installieren. Hier ist der einfachste Fall:

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

wobei A eine Version eines Pakets ist, und A' eine andere Version desselben Pakets ist. Da B von einer anderen Version von A abhängt als der, die bereits im Baum vorhanden ist, muss es eine separate Kopie installieren. Dasselbe gilt für A', das B' installieren muss. Da B' von der ursprünglichen Version von A abhängt, die überschrieben wurde, fällt der Zyklus in einen unendlichen Regress.

Um diese Situation zu vermeiden, weigert sich npm pauschal, einname@version zu installieren, das bereits irgendwo im Baum der Paketordner-Vorfahren vorhanden ist. Eine korrektere, aber komplexere Lösung wäre es, die bestehende Version per Symlink an den neuen Ort zu bringen. Sollte dies jemals einen realen Anwendungsfall betreffen, wird dies untersucht werden.

Siehe auch

• 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