Eine Anleitung zu npm: Der Node.js-Paketmanager

Veröffentlicht: 2022-03-11

JavaScript ist mit Abstand die am häufigsten verwendete Sprache, wenn es um die Entwicklung von Websites und Webanwendungen geht. Die Vielfalt der Ressourcen ist erstaunlich, und noch mehr die Anzahl der verfügbaren Bibliotheken.

Zunächst sind diese Bibliotheken wenige und einfach zu warten; Doch schon bald setzt die Abhängigkeitshölle ein und eine ausgereiftere Lösung ist erforderlich.

npm ist wahrscheinlich der beliebteste Paketmanager für JavaScript.

Geben Sie den Node Package Manager (npm) ein – einen JavaScript-Paketmanager, der vor allem in Verbindung mit Node.js verwendet wird, obwohl er auch unabhängig verwendet werden kann. Es gibt Ihnen eine außergewöhnliche Kontrolle über die Abhängigkeiten Ihres Projekts und bietet eine großartige Möglichkeit, einen Beitrag zur Open-Source-Welt zu leisten.

Sie können beginnen, indem Sie einfach npm install <package name> ausführen und es in Ihre JavaScript-Datei einfügen.

Möchten Sie eine bestimmte Version installieren? Kein Problem. Führen Sie npm install <package name>@1.2.3 .

Möchten Sie ein Paket global installieren (wie Mocha oder Angular-CLI)? Fügen Sie einfach ein -g wie folgt hinzu: npm install -g angular-cli mocha .

Zugegeben, die meisten Anwendungsfälle enden bei einer npm-Installation, und es besteht keine Notwendigkeit für etwas anderes. npm hat jedoch viele zusätzliche Funktionen, die ich Ihnen erklären werde, wobei ich diejenigen hervorhebe, die ich für wesentlich, wirklich nützlich oder einfach nur großartig halte.

CLI-Befehle

Die CLI ist der Ort, an dem Benutzer die meiste Zeit mit der Interaktion mit npm verbringen, und ihre Hilfeschnittstelle ist tatsächlich hilfreich.

Das Abfragen von Hilfe ( npm help ) spuckt eine ganze Reihe von Optionen aus, und wenn Sie npm help-search <searchText> , erhalten Sie eine Liste mit Suchergebnissen direkt aus dem npm-Markdown.

Hier sind die Kernbefehle, die auffallen.

  • install : Es wird hier wegen seiner reinen Notwendigkeit bei der Arbeit mit npm erwähnt. Wird verwendet, um entweder ein neues Paket lokal oder global zu installieren (beim Hinzufügen von -g ) oder um Abhängigkeiten zu installieren, die in der Datei „ package.json “ aufgeführt sind (dazu später mehr).

  • uninstall : Dies ist ebenfalls ein Muss. Es wird verwendet, um ein bestimmtes Paket entweder lokal oder global (beim Hinzufügen von -g ) aus dem Verzeichnis node_modules zu löschen.

  • access : Dies ist die Spielwiese von npm-Benutzerberechtigungsadministratoren im Kontext von npm-Organisationen und bereichsbezogenen (privaten) Paketen. Wirklich starkes Zeug. In Verbindung mit adduser , owner , team usw. verwendet, gibt es eine feinkörnige Kontrolle darüber, wer Zugriff auf was hat.

  • bin : Wo um alles in der Welt werden Pakete installiert? Führen Sie diesen Befehl aus, um den absoluten Dateipfad anzuzeigen.

  • cache : Wenn Sie beginnen, Pakete von npm left, right und center zu installieren, ist dieser Befehl sehr nützlich. Rufen Sie es entweder mit dem Unterbefehl ls auf, um eine Liste der lokal zwischengespeicherten Pakete anzuzeigen, oder mit dem Unterbefehl clean , um alle Pakete zu löschen, die sich im Cache befinden. Als die npm-Registrierung noch etwas instabil war, war dies unerlässlich, um zu einer stabilen Umgebung zurückzukehren oder Dinge zurückzusetzen, wenn Sie npm-Berechtigungen nicht richtig eingerichtet haben.

  • config : Wir werden später auf die verschiedenen Konfigurationsoptionen eingehen, aber dieser Befehl befasst sich hauptsächlich mit dauerhaften Konfigurationseigenschaften in der lokalen oder globalen Konfigurationsdatei, indem die Unterbefehle set , get oder delete verwendet werden.

  • dedupe oder ddp : Wenn Sie über einen längeren Zeitraum an einem Projekt arbeiten und Pakete direkt von npm installieren, durchläuft dieser Befehl den lokalen Paketbaum und versucht, Abhängigkeiten zu vereinfachen.

  • link : Wenn Sie Ihr eigenes npm-Paket entwickeln, können Sie damit einen symbolischen Link zum globalen Kontext erstellen, sodass es getestet werden kann, als ob es global aus der npm-Registrierung installiert wurde. Wenn Sie beispielsweise ein Assembly-Tool in einem Knoten schreiben, auf dem eine CLI global installiert ist, können Sie diesen Befehl ausführen und das Verhalten Ihrer CLI testen, ohne sie zuerst bereitstellen zu müssen.

  • ls : Es wird verwendet, um Paketabhängigkeiten und ihre Abhängigkeiten in einer Baumstruktur zu visualisieren. Es ist cool zu sehen und ist auch nützlich für Vergleiche mit anderen Projekten.

  • outdated : Dies wird verwendet, um den aktuellen Zustand der installierten Abhängigkeiten zu bewerten und ob sie veraltet sind oder nicht. In Projekten, in denen die Root-Abhängigkeitsliste Hunderte von Zeilen lang ist, ist eine manuelle Überprüfung der Pakete nahezu unmöglich. Durch Hinzufügen -g --depth=0 zu diesem Befehl können Sie auch Ihre global installierten Pakete überprüfen.

  • publish : Dieser Befehl ist unerlässlich, wenn Sie Ihr eigenes Paket für npm entwickeln. Es tut genau das, was der Name vermuten lässt; Es veröffentlicht Ihr Paket in der npm-Registrierung.

  • search : Verwenden Sie dies, um die Registrierung nach allen Paketen zu durchsuchen, die den im dritten Argument angegebenen Text enthalten.

  • shrinkwrap : Kurz gesagt, mit diesem Befehl können Sie bestimmte Abhängigkeitsversionen in einem Paket der Reihe nach sperren, sodass eine entspannte Semver-Nummer (semantische Versionierung) den Produktionscode nicht beschädigt.

  • star : Gefällt Ihnen ein Paket, das Sie verwenden, wirklich? Verwenden Sie diesen Befehl, um Ihre Wertschätzung direkt vom Terminal aus zu zeigen, was sich dann auf der Seite des Pakets in der npm-Registrierung widerspiegelt.

  • update : Dies folgt normalerweise auf den outdated Befehl, um veraltete Pakete zu aktualisieren.

  • version : Dies gibt Ihnen eine Abkürzung, um die Versionseigenschaft package.json zu stoßen und ein Git-Tag in einem zu erstellen.

Beachten Sie, dass die meisten dieser Befehle Unterbefehle und/oder Konfigurationen annehmen können und diese Liste keinesfalls eine abschließende Diskussion über die CLI darstellt.

npm-config

Die Konfiguration ist ein wichtiger Teil von npm, und es gibt mehrere Möglichkeiten, Konfigurationsvariablen festzulegen.

Konfiguration über CLI und Umgebungsvariablen

Zunächst kann die Konfiguration über die CLI vom Terminal aus vorgenommen werden.

Normalerweise würde es ungefähr so ​​aussehen: npm <command> --<configuration option> [<optional value>] .

Wenn der Wert nicht angegeben ist, wird die Option standardmäßig auf „true“ gesetzt.

Angenommen, Sie arbeiten an einem bereichsbezogenen (privaten) npm-Paket und entscheiden sich, es als öffentliches Paket zu veröffentlichen.

Dies geht ganz einfach, indem --access=public an Ihren publish anhängen. Wenn wir die Eigenschaft nicht als öffentlich angeben, wäre der Standardwert eingeschränkt (privat).

An andere Befehle angehängte Konfigurationen dieser Art bleiben nicht überall erhalten, sodass es lästig werden kann, eine Reihe von Konfigurationen über die CLI festzulegen.

In diesen Fällen kann es besser sein, die Konfiguration mithilfe von Umgebungsvariablen festzulegen.

Jede Umgebungsvariable mit dem Präfix npm_config_ wird zum Konfigurieren von npm verwendet.

Beispiel: export npm_config_registry=localhost:4321 würde die Registrierungskonfigurationsoption global festlegen, und wenn npm ausgeführt wird, verwendet es die npm-Registrierung, die sich auf localhost auf Port 4321 befindet.

Konfiguration über die npmrc-Datei

Sie können auch Konfigurationsoptionen mit der speziellen .npmrc -Datei festlegen, die je nach Ihren Anforderungen auf verschiedenen Ebenen festgelegt werden können:

  • Projektebene: Im Stammverzeichnis des Codes eines Projekts zusammen mit der Datei „ package.json “, normalerweise path/to/project/.npmrc
  • Benutzerebene: Das Verzeichnis, das das Konto eines bestimmten Benutzers konfiguriert, normalerweise ~/.npmrc
  • Globale Ebene: Das Verzeichnis, in dem npm nach globalen Konfigurationen sucht, normalerweise $PREFIX/etc/npmrc
  • Eingebaute Wasserwaage: Seien Sie vorsichtig. Diese Konfiguration ist nicht nur global, sondern auch Teil des npm-Quellcodes, und Best Practice empfiehlt (tatsächlich fordert), dass wir Code, für dessen Wartung wir nicht verantwortlich sind, nicht ändern. Es kann normalerweise unter /path/to/npm/npmrc .

Konfigurationseinstellungen in der .npmrc -Datei können mithilfe der CLI geändert und beibehalten werden, indem ein Befehl in diesem Format ausgeführt wird: npm config set <key> <value> .

Beispielsweise können Sie npm config set access public ausführen, um die Veröffentlichungskonfiguration eines bereichsbezogenen (privaten) Pakets dauerhaft öffentlich zu machen.

Standardmäßig würde dieser Befehl die Konfiguration lokal beibehalten (die Konfiguration auf Benutzerebene, wie oben beschrieben), aber Sie können -g hinzufügen, um sie global zu speichern.

Wenn eine dauerhafte Konfiguration auf Projektebene oder auf der integrierten Ebene erfolgen muss, muss die .npmrc -Datei mit einem Texteditor geändert werden.

Konfiguration über package.json

Schließlich kann die Konfiguration aus der Datei package.json “ festgelegt werden. Dies wird jedoch selten verwendet (und sollte nur verwendet werden, wenn dies ausdrücklich erforderlich ist), da eine .npmrc -Datei auf Projektebene der herkömmlicherweise bevorzugte Ort zum Festlegen der Paketkonfiguration ist.

Bemerkenswerte Konfigurationseinstellungen

  • access : Wie oben besprochen, wird es verwendet, um Berechtigungen festzulegen.

  • always-auth : Es ist wichtig zu beachten, dass diese Einstellung standardmäßig auf false gesetzt ist. Wenn es auf „true“ gesetzt ist, erfordert npm beim Kontaktieren der Registrierung immer eine Authentifizierung.

  • ca : Standardmäßig die npm-Zertifizierungsstelle (CA). Es kann auf null geändert werden, um nur bekannten Registraren Zugriff zu gewähren, oder auf ein bestimmtes CA-Zertifikat, um nur diesem bestimmten Zugriff zu gewähren. Diese Einstellung wird zusammen mit cafile , cert und strict-ssl selten verwendet, spricht jedoch für den Sicherheits- und Zuverlässigkeitsaspekt von npm und gibt Ihnen die Gewissheit, dass das von Ihnen installierte Paket aus der erwarteten Quelle stammt.

  • color : Dies ist standardmäßig true, was Ihnen eine Pause von der Standardtrostlosigkeit des Terminals verschafft, indem Sie die Standardausgabe einfärben, die von tty- stdout zugelassen wird. Wenn auf false gesetzt, bleibt das Terminal dumpf. Wenn es auf always gesetzt ist, wird es immer in Farbe ausgegeben.

  • depth : Diese Einstellung ermöglicht eine granulare Kontrolle darüber, was Sie mit rekursiven Befehlen wie ls und outdated sehen, indem Sie zuweisen, wie tief sie ausgeführt werden. Ein Wert von 0 wertet nur die erste Ebene von Abhängigkeiten aus, während Unendlich (die Standardeinstellung) bewirkt, dass alle Ebenen von Abhängigkeiten evaluiert werden. Die Ausnahme von dieser Regel ist die Verwendung mit outdated ; In diesem Fall wird unendlich als 0 interpretiert, um eine relevantere Ausgabe zu gewährleisten.

  • dev : Dies ist standardmäßig auf false gesetzt, aber wenn es auf true gesetzt ist (bei einer npm install ), werden alle Entwicklungsabhängigkeiten in der Datei package.json zusammen mit den normalen Abhängigkeiten installiert.

  • dry-run : Wenn diese Einstellung auf true gesetzt ist, nimmt npm keine Änderungen an Ihrem Paket vor, sondern teilt Ihnen stattdessen mit, was es getan hätte. Dies kann sehr nützlich sein, wenn bestimmte Befehle ausgeführt werden, z. B. dedupe oder update .

  • git-tag-version : Es ist standardmäßig auf true gesetzt. Diese Einstellung markiert eine Version in Git, wenn der Befehl npm version ausgeführt wird. Wenn Sie npm als Paketmanager für ein großes Projekt mit getaggten Versionen in Git verwenden, können Sie Zeit sparen und daran denken, die Datei „ package.json “ für Sie zu aktualisieren.

  • loglevel : Standardmäßig ist dies auf warn eingestellt, wodurch beim Ausführen von npm-Befehlen ein Fehler und eine Warnung ausgegeben werden. Andere Einstellungen umfassen silent , das keine Ausgabe bereitstellt; error , der nur Fehler in der Ausgabe protokolliert; http , das nur HTTP-Anforderungsfehler ankündigt; info , für eine informative Ausgabe); verbose , das fast alles protokolliert; und silly , was, wie der Name schon sagt, eine alberne Menge an Ausgabe und noch mehr liefert.

  • production : Wenn dies auf true gesetzt ist, verhält sich npm entsprechend und führt alle Befehle im Produktionsmodus aus. Das bedeutet, dass keine Entwicklungs- oder optionalen Abhängigkeiten installiert werden und keine entwicklungsbezogenen Aufgaben ausgeführt werden.

  • rollback : Wenn auf true gesetzt, werden alle fehlgeschlagenen Installationen entfernt. Dies ist praktisch, wenn eine Installation von Abhängigkeiten fehlschlägt. Abhängig von Ihrer Protokollierungsstufe sollten Sie sehen können, welche Installationen fehlgeschlagen sind, diese notieren und den Befehl npm install mit der Rollback-Option auf true ausführen. Dann können Sie mit Ihren Notizen und einer Trockeninstallation (wie oben beschrieben) das Problem beheben.

  • 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, fügt npm install lodash` lodash zu Ihren Abhängigkeiten hinzu.

  • save-dev : Ähnlich wie bei der Option save configuration fügen --save-dev hinzu, wenn Sie ein Paket installieren, und es wird dann zur Option devDependencies in der Datei package.json .

  • save-optional : Ähnlich wie bei der Option save configuration fügen --save-optional hinzu, wenn Sie ein Paket installieren, und es wird dann zur Option optionalDependencies in der Datei package.json .

  • save-exact : Beim Installieren von Paketen ändern die Optionen save , save-dev und save-optional die Datei package.json , indem sie das installierte Paket mit einem semver-Bereichsoperator in die entsprechende Eigenschaft einfügen. Beim Aufrufen der Konfigurationseinstellung „save-exact“ mit dem Wert „true“ in Verbindung mit einer der oben genannten Einstellungen wird eine spezifische Versionsnummer verwendet, wobei der Semver-Bereich ignoriert wird.

  • save-prefix : Dies setzt den Semver-Bereichsoperator bei Verwendung von save , save-dev oder save-optional . Der Standardwert ist ^ , was kleinere Upgrades von Paketen bei der Installation ermöglicht. Dies kann auf jeden gültigen Semver-Bereichsoperator mit Präfix gesetzt werden.

  • tag-version-prefix : Der herkömmliche Standardwert ist v , der angibt, was der git-Tag-Version vorangestellt wird, wenn npm version ausgeführt wird.

Aktualisieren von npm Mit npm

Sie können npm auch verwenden, um sich selbst zu aktualisieren.

Führen Sie einfach npm install -g npm@latest aus, und npm wird auf die neueste stabile Version aktualisiert. Es ist wichtig zu beachten, dass jede Version von Node.js mit einer bestimmten Version von npm ausgeliefert wird, und meiner Erfahrung nach sollten Sie sich nicht zu sehr mit dieser Paarung anlegen.

Am Ende des Tages ist meine Empfehlung, bei der Paarung zu bleiben, wie sie beabsichtigt ist.

Wenn Sie npm als eigenständiges Tool verwenden, stellen Sie sicher, dass Sie die Auswirkungen der Verwendung der von Ihnen gewählten Version verstehen. Es gibt ein großartiges Tool zum Verwalten verschiedener Node.js-Versionen (und wiederum npm-Versionen) auf demselben System namens nvm.

Die Datei „package.json“.

Die Datei package.json ist das entscheidende Element, das alles miteinander verbindet.

Es ist eine Voraussetzung für die Veröffentlichung eines Pakets in der npm-Registrierung, und hier wird der Verwaltungsteil von Abhängigkeiten zum Leben erweckt.

Es hat zwei erforderliche Felder, nämlich „Name“ und „Version“, und zusammen sollten diese Eigenschaften eine eindeutige Kennung sein.

Das Namensfeld sollte bestimmten Regeln entsprechen, die in der npm-Dokumentation zur Benennung definiert sind, und das Versionsfeld unterliegt den semver-Spezifikationen.

npm liest die Datei „package.json“ für die Abhängigkeitsverwaltung.

Darüber hinaus können Sie eine meilenlange Liste von Abhängigkeiten haben und eine bestimmte Version definieren, die für jede von ihnen verwendet werden soll, indem Sie die Semver-Versionen und Bereichsoperatoren verwenden. Hier ist eine Liste anderer bemerkenswerter Eigenschaften.

"hauptsächlich"

„main“ definiert den Einstiegspunkt zu Ihrer Anwendung, die standardmäßig index.js . Je nach Konvention oder Ihrem Framework kann es sich um app.js oder main.js . Sie können natürlich alles machen, was Sie wollen.

„Skripte“

Dies ist eine unterschätzte Eigenschaft.

Erstens kann es verwendet werden, um Dinge vor der Veröffentlichung zu erledigen.

Zweitens bietet es einen Ort, an dem Sie eine Reihe häufig verwendeter Befehle aliasieren können, angefangen von Build-Aufgaben (definiert in gulp oder grunt), das Auslösen der Installation anderer Abhängigkeiten (mit so etwas wie Bower), das Starten eines Entwicklungsservers mit Webpack oder Ausführen einer Reihe von Bash-Befehlen.

„Abhängigkeiten“

Diese Eigenschaft ist eine Liste von Paketen, die von Ihrer Anwendung benötigt werden, zusammen mit der kompatiblen Semver-Nummer. Dies ist eine bemerkenswerte Eigenschaft, da sie vom Terminal aus geändert werden kann, wenn Sie lokale Pakete installieren.

Dies geschieht durch Hinzufügen von --save (oder der Abkürzung -S ) am Ende des Befehls npm install .

Wenn Sie dies tun, werden die neu installierten Pakete der Liste der Abhängigkeiten in Ihrer Datei package.json “ hinzugefügt.

In ähnlicher Weise kann eine Abhängigkeit auch entfernt werden, indem --save hinzufügen, wenn Sie den Befehl npm uninstall uninstall ausführen.

Es ist wichtig, sich der Semver-Versionierungsmuster jeder der Abhängigkeiten und ihrer Bedeutung bewusst zu sein.

Wenn die Semver-Regel zu streng ist, verlieren Sie neue Funktionen und Verbesserungen, während bei einer zu lockeren Semver-Regel eine kaputte Version eines Pakets nach und nach installiert werden kann.

Eine fehlerhafte Paketinstallation kann sich als ziemlich schwierig zu beheben erweisen, insbesondere wenn die minimierte Version des Pakets verwendet wird.

„devAbhängigkeiten“

Unabhängig von der Eigenschaft „dependencies“ ermöglicht Ihnen die Eigenschaft „devDependencies“, Abhängigkeiten zu definieren, die nur während der Entwicklungsphase verwendet werden und für den Produktions-Build nicht erforderlich sind (wie ESLint, Grunt-Contrib-Pakete und Protractor). Genau wie bei Abhängigkeiten kann diese Eigenschaft vom Terminal aus geändert werden, indem --save-dev (oder die Abkürzung -D ) am Ende des Befehls npm install oder des Befehls npm uninstall uninstall hinzugefügt wird. Die gleiche Vorsicht gilt für die Versionierung wie unter Abhängigkeiten erwähnt.

"Behälter"

Hier können Sie die ausführbare(n) Datei(en) Ihres Pakets angeben, z. B. den Pfad zu einem CLI-Dienstprogramm. Diese Eigenschaft weist npm an, lokale oder globale Symlinks zu Ihren ausführbaren Dateien zu erstellen, wenn Ihr Paket installiert wird.

„konfigurieren“

Wie bereits erwähnt, definieren Sie hier Konfigurationseinstellungen über Ihre Datei package.json “.

"Privat"

Wenn es auf true gesetzt ist, weigert sich npm, das Paket zu veröffentlichen.

Dies sollte nicht mit der Zugriffskonfigurationseinstellung verwechselt werden.

Dies ist eine praktische Einstellung, wenn Sie ein Projekt haben, das npm zusammen mit seiner package.json , aber nicht für die Veröffentlichung in der npm-Registrierung vorgesehen ist, weder im Umfang noch in der Öffentlichkeit.

Wenn sich Ihre Absicht ändert, ändern Sie die Einstellung einfach auf „false“ und Sie können Ihr Paket veröffentlichen.

Benutzerdefinierte Eigenschaften

Die Datei package.json “ akzeptiert auch benutzerdefinierte Eigenschaften, solange der Name nicht bereits definiert oder reserviert ist.

Entwicklung Ihres eigenen npm-Pakets

Das npm-Ökosystem ist mit Paketen gefüllt, die von Tausenden verschiedener Entwickler auf der ganzen Welt geschrieben wurden. Jeder löst irgendein Problem, liefert eine Abstraktion oder präsentiert eine Implementierung von etwas.

Die Chancen stehen gut, dass auch Sie irgendwann Ihr eigenes Paket zum Teilen entwickeln möchten.

Zuerst müssen Sie eine Datei „ package.json “ mit den mindestens erforderlichen Eigenschaften „name“ und „version“ erstellen und dann die Eigenschaft „main“, um den Einstiegspunkt anzugeben, z. B. „index.js“.

Schreiben Sie Ihren Code in diese index.js-Datei, melden Sie sich mit Ihrem npm-Benutzerkonto an oder erstellen Sie einen neuen Benutzer über das Terminal, und Sie können ihn in der npm-Registrierung veröffentlichen.

Pakete können öffentlich oder privat sein.

Öffentliche Pakete können kostenlos veröffentlicht werden und stehen allen zur Nutzung zur Verfügung.

Private Pakete, sogenannte Scoped Packages, können nur veröffentlicht werden, wenn Sie einen bezahlten Benutzer für private Module haben, und sie können durch den eindeutigen @username/ identifiziert werden, der dem Paketnamen vorangestellt ist.

Umfasste Pakete können auch öffentlich veröffentlicht werden, indem der Befehl publish mit --access=public .

Wenn Sie außerdem etwas mehr Zeit damit verbringen, die Codebasis Ihres Pakets zu erweitern und zu verbessern, und es an der Zeit ist, eine neue Version zu veröffentlichen, ändern Sie einfach die Version (gemäß den Semver-Regeln und -Konventionen) des Pakets in der package.json file und npm publish ein.

Sie können auch die Befehlszeilenschnittstelle verwenden und npm version <update_type> , wobei update_type entweder patch , minor oder major ist, wie von semver beschrieben, und dies erhöht dann automatisch die Versionsnummer in der Datei package.json .

npm-Organisationen

Auch hier ist die npm-Dokumentation dafür ausgezeichnet, und es wäre sinnlos, ihre Worte einfach zu wiederholen.

Was über Organisationen im npm-Kontext gesagt werden kann, ist, dass sie extrem feinkörnig sind, und wenn sie richtig verwaltet werden, können große Teams und Einzelpersonen, die an Scope- oder öffentlichen Paketen unter einem Namen arbeiten, sehr gut verwaltet und eingeschränkt werden.

Obwohl es komplex zu meistern ist, ist es sehr lohnend.

Die Macht von npm

Letztendlich ist die von npm bereitgestellte Dokumentation umfangreich und sollte für Einzelheiten konsultiert werden, aber dieser Artikel bietet einen nützlichen Überblick über grundlegende und fortgeschrittenere, beteiligte Funktionen und vermittelt die Großartigkeit von npm.

Wie bei allen Dingen gibt es starke Meinungen und viele Fehler können gefunden werden. Aber wenn Sie npm (oder Knoten, was das angeht) noch nie ausprobiert haben, tauchen Sie ein und erkunden Sie es selbst. Die Chancen stehen gut, dass Sie es mehr genießen werden, als Sie denken.

Weitere interessante Artikel zu npm finden Sie unter Verwenden von Scala.js mit npm und Browserify.