Wenn Sie mitzählen, haben wir bisher in diesem npm-Leitfaden ein allgemeines Verständnis davon entwickelt, was npm ist – insbesondere, dass es für Node Package Manager steht. Dabei haben wir die Bedeutung der Befehlszeile und ihre Verwendung mit npm besprochen.
Wir haben uns auch speziell mit dem „n“ in npm beschäftigt – Node – und gelernt, dass Node dem JavaScript-Code, den wir für die Ausführung auf Websites in einem Browser schreiben, sehr ähnlich ist. Tatsächlich *ist* Node JavaScript; es läuft nur außerhalb des Browsers und kann andere Dinge tun als sein browserbasiertes Gegenstück.
Kapitel des Leitfadens
- Für wen ist diese Anleitung?
- Was zum Teufel bedeutet „npm“?
- Was zum Teufel ist die Befehlszeile?
- Was zum Teufel ist Node?
- Was zum Teufel ist ein Paketmanager? (Sie sind hier!)
- Wie zum Teufel installiert man npm?
- Wie zum Teufel installiert man npm-Pakete?
- Was zum Teufel sind npm-Befehle?
- Wie zum Teufel installiert man ein bestehendes npm-Projekt?
Was wir unter „Paket“ verstehen
Nun wenden wir uns den letzten beiden Buchstaben von npm zu, nämlich dem Teil „Paketmanager“. Um vollständig zu verstehen, was npm ist, müssen wir wissen, was ein Paketmanager ist. Folglich müssen wir, um *das* zu verstehen, zuerst verstehen, was zum Teufel ein „Paket“ ist.
„Paket“ ist ein Sammelbegriff für alle externen Code-Dateien, die Sie in ein Projekt ziehen und auf irgendeine Weise verwenden. Vielleicht haben Sie in der Vergangenheit jQuery, Bootstrap oder Axios in einem Projekt verwendet. Das sind gängige Beispiele für Pakete.
Wir nennen sie „Pakete“, weil sie „verpackt“ und gebrauchsfertig sind. Einige Sprachen nennen sie anders (Ruby nennt sie zum Beispiel „Gems“), aber das Konzept ist dasselbe. Auf die Gefahr hin, zu vereinfachen: Ein Paket ist Code, den Sie nicht selbst geschrieben haben, sondern aus einer öffentlichen Quelle bezogen haben, um ihn in Ihrem Projekt zu verwenden. Sie wissen schon, Drittanbieter-Code.
Oder, wenn Sie musikalische Parodien für Ihre Merkhilfen bevorzugen
🎵 Wenn es Code gibt, den du wählst
🎵 Der nicht deiner ist, aber den du nutzt
🎵 Das ist ein Paket
🎵 Wenn es Zeug ist, das du installierst
🎵 Das du importierst und aufrufst,
🎵 Das ist ein Paket
Pakete werden auch oft als „Abhängigkeiten“ bezeichnet, da der Code, den Sie schreiben, von ihrer Anwesenheit *abhängt*. Code, der mit dem $ von jQuery geschrieben wurde, funktioniert beispielsweise nicht richtig, wenn jQuery selbst nicht bereits geladen ist. (Aus diesem Grund werden Paketmanager auch manchmal als „Abhängigkeitsmanager“ bezeichnet.)
Pakete können groß oder klein sein, je nachdem, wie viel Code sie enthalten. Ein Paket kann etwas Riesiges tun, das die Art und Weise, wie Sie Ihr gesamtes Projekt schreiben, verändert (wie ein komplettes Framework), oder es kann etwas sehr Kleines und Fokussiertes tun, das Sie nur dort einstreuen, wo es benötigt wird (wie ein Widget oder ein Helfer für eine bestimmte Aufgabe).
Pakete ohne Paketmanager verwenden
Wenn Sie in der Vergangenheit ein Paket verwendet haben, haben Sie es höchstwahrscheinlich einfach mit einem Skript-Tag im HTML eingebunden, das von einer externen URL lädt (idealerweise von einem CDN). So könnten Sie jQuery in das HTML Ihrer Website einbinden
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>Ein anderer Ansatz ist, eine Kopie des Pakets herunterzuladen, es zu den Dateien Ihres Projekts hinzuzufügen und lokal darauf zu verlinken, so:
<script src="/jquery.min.js"></script>Was Paketmanager lösen
Diese beiden Ansätze haben jahrelang gut funktioniert. Es ist einfach. Es ist sauber. Es lässt Sie das Paket im Allgemeinen „einrichten und vergessen“. Warum sollten Sie also etwas anderes brauchen?
Sie können sich wahrscheinlich vorstellen, wie der Besitz eines Autos für jemanden, der bequemen öffentlichen Nahverkehr hat oder keine Langstreckenreisen benötigt, unattraktiv erscheinen könnte. (Das wird sich auf das Thema Paketmanager zurückführen, ich verspreche es. Bleiben Sie dabei.)
Wenn Sie einfachen Zugang zu einem bequemen und effizienten öffentlichen Nahverkehr haben, dann ist das Bezahlen eines hohen Preises für eine massive Maschine, die Sie irgendwo lagern, regelmäßig reinigen, warten und mit teurem Kraftstoff füllen müssen, wahrscheinlich aus Ihrer Sicht nicht sehr vorteilhaft. In diesem speziellen Fall sind die Vorteile vernachlässigbar; die Kosten sind im Vergleich überwältigend. Jemand in dieser hypothetischen Situation fragt sich vielleicht sogar, warum überhaupt jemand ein Auto will!
Ich bringe diese Analogie, weil das Erlernen einer neuen Technologie sehr schwierig sein kann, wenn *sie ein Problem löst, das Sie nicht haben*, ganz so, wie der Kauf eines Autos den Transport, den Sie bereits haben, nicht lösen mag. Es mag wie eine massive, unnötige Ausgabe erscheinen.
Was ein Paketmanager dann löst, ist eher eine Frage der Skalierung und der Handhabung von Belangen. Das einfache Verlinken eines Pakets in einem Skript-Tag funktioniert gut, solange
- die Anzahl der Projekte, die Sie haben, überschaubar ist;
- die Anzahl der Personen, die an den Projekten arbeiten, überschaubar ist;
- die Anzahl der Updates, die für die Pakete vorgenommen werden müssen, überschaubar ist; und, am wichtigsten,
- jedes Paket, das in Ihren Projekten verwendet wird, clientseitiges (Browser) JavaScript oder CSS ist.
Das Letzte ist das Entscheidende, denn es gibt eine Fülle von Werkzeugen, die Sie niemals verwenden können, wenn Sie *nur* Dinge im Browser ausführen (mehr dazu gleich).
Wenn Sie all diese Kriterien erfüllen, sind Sie mit diesem Ansatz möglicherweise nie überfordert. Ihr Entwicklungsansatz sieht dann vielleicht so aus:
Aber selbst in diesem Fall, wenn Sie mehrere <script>-Tags haben, die jeweils auf eine bestimmte Version eines Skripts oder einer Bibliothek verlinken, ist der *einzige* Weg, überhaupt eine Übersicht darüber zu bekommen, welche Pakete Sie verwenden und ob sie aktuell sind, die HTML-Datei manuell zu öffnen und den Code anzusehen.
Das ist an sich kein großes Problem, aber es ist ein Problem, das exponentiell wächst, je größer und umfangreicher ein Projekt wird. Sie können vielleicht ein paar Pakete manuell verfolgen, aber wie könnten Sie das tun, wenn wir über Hunderte – wenn nicht Tausende – von Paketen sprechen? Und selbst wenn Sie diese manuell verfolgen könnten, würde dies immer noch ein hohes Risiko menschlicher Fehler einführen.
Es ist nicht die Aufgabe von HTML, die einzige Quelle für alle Pakete zu sein, die in einem Projekt verwendet werden. Abgesehen davon, dass Bedenken vermischt werden, kann dies auch zu Konflikten führen, wenn Sie versuchen, nicht zusammengehörige Arbeiten zwischen Teammitgliedern zusammenzuführen.
Das alles ist wichtig, aber es ist der kleinste Teil eines größeren Problems. Verstehen Sie, dass clientseitiges JavaScript wahrscheinlich nicht die *einzige* Art von Paket ist, die Sie für immer in Ihre Projekte einbinden möchten, selbst wenn es im Moment so ist – und hier beginnen die Dinge *wirklich* zu zerfallen.
Viele Produktions-Apps verwenden eine Kombination der folgenden Tools und Pakete, wenn nicht sogar alle:
- Sass (erleichtert das Schreiben von CSS)
- PostCSS (verbessert CSS für maximale Effizienz und Kompatibilität)
- Babel (transpiliert neuere JavaScript, um in älteren Browsern zu laufen)
- TypeScript (fügt JavaScript Typüberprüfung hinzu)
- Hot Module Reloading durch einen Entwicklungsserver, der den Browser automatisch neu lädt, um Ihre Änderungen anzuzeigen
- Zusätzliche Dienstprogramme für Code-Bundling, Minifizierung und/oder Verkettung
- Automatische Bildkomprimierung
- Testbibliotheken
- Linter
Das klingt alles wunderbar – und das ist es auch! –, aber bemerken Sie, dass Sie jetzt mehrere Abhängigkeiten haben, die nicht nur *nicht* in Ihren Skript-Tags vorhanden sind, sondern *überhaupt nicht in Ihrem Projekt erfasst sind*! Es gibt keine Möglichkeit für irgendjemanden – einschließlich Ihres zukünftigen Ichs –, irgendeine Vorstellung davon zu haben, welche Tools verwendet wurden oder erforderlich sind, um dieses Projekt zum Laufen zu bringen.
Und selbst wenn Sie genau wüssten, was das Projekt auf diese Weise benötigte, müssten Sie immer noch all diese Pakete selbst finden, herunterladen und installieren… manuell. Je nach Projekt könnte dies leicht ein ganzer Tag oder länger dauern.
All das bedeutet, dass Ihr Workflow jetzt eher so aussieht:
So praktisch all die oben genannten Tools auch sind, Sie müssen sie immer noch *verwalten*. Abhängigkeiten sind auch Projekte, und sie veröffentlichen Updates, um Fehler zu beheben und neue Funktionen einzuführen. Daher ist es unrealistisch, einfach ein Skript-Tag in das HTML einzufügen, das auf ein Paket auf einem CDN verweist, und es dann dabei zu belassen. Sie müssen sicherstellen, dass jedes Ding installiert ist und richtig funktioniert, nicht nur auf *Ihrem* Computer, sondern auch auf dem Computer jedes Mitarbeiters.
Paketmanager existieren, um die Pakete – oder Abhängigkeiten – eines Projekts verwaltbar zu machen, indem sie wissen, was installiert ist, was zum Aktualisieren verfügbar ist und ob ein Paket mit einem anderen in Konflikt geraten könnte. Und das Schöne an einem Paketmanager ist, dass er all das direkt von der Befehlszeile aus mit minimalem Aufwand erledigt.
Viele Paketmanager, insbesondere npm, bieten auch zusätzliche Funktionen, die noch mehr Möglichkeiten eröffnen, die Entwicklung effizienter zu gestalten. Aber die Verwaltung von Paketen ist der Hauptanziehungspunkt.
Es gibt Paketmanager, die nicht npm sind
Dieser Teil ist für npm selbst nicht besonders relevant, aber der Vollständigkeit halber sollte ich auch erwähnen, dass npm nicht der *einzige* JavaScript-Paketmanager ist. Zum Beispiel sehen Sie vielleicht Yarn in Codebeispielen erwähnt. Yarn und npm funktionieren weitgehend gleich, sodass ein hohes Maß an Interoperabilität zwischen beiden bewusst integriert ist.
Einige Leute bevorzugen einen Paketmanager gegenüber einem anderen. Persönlich denke ich, dass die Unterschiede zwischen npm und Yarn anfangs ausgeprägter waren, aber die beiden sind sich jetzt ähnlicher als nicht.
Sie sehen vielleicht Codebeispiele (einschließlich einiger in CSS-Tricks-Artikeln), die sowohl yarn als auch npm zusammen erwähnen. Das soll dem Leser mitteilen, dass beide Ansätze in Ordnung sind, anstatt dass beide zusammen verwendet werden müssen.
Die Syntax für Yarn und npm unterscheidet sich manchmal, aber wo nur einer vorhanden ist, ist es im Allgemeinen trivial, einen Befehl oder ein Projekt von einem zum anderen zu konvertieren. Funktional spielt es selten (wenn überhaupt) eine Rolle, welchen Sie verwenden – außer natürlich, dass jeder, der gemeinsam an demselben Projekt arbeitet, denselben verwenden möchte, um Kompatibilität und Konsistenz zu gewährleisten.
Während npm und Yarn den größten Teil der von Entwicklern verwendeten Paketmanager ausmachen, gibt es einen weiteren Paketmanager namens PnPm, der im Wesentlichen npm, aber leistungsfähiger und effizienter ist. Der Nachteil ist, dass PnPm in einigen Fällen etwas mehr technisches Wissen erfordert, sodass es sich um eine etwas fortgeschrittenere Option handelt.
Was macht npm zum „Standard“-Paketmanager
Nochmals, ich erwähne andere Paketmanager nur, um zu veranschaulichen, dass npm nicht der einzige Paketmanager da draußen ist – aber es ist im Allgemeinen der Standard.
Was macht ihn zum „Standard“ unter den Paketmanagern? Andere Sprachen, darunter Ruby und PHP, haben schon seit vielen Jahren Paketmanager; JavaScript hatte vor npm wirklich keine guten.
npm begann als unabhängiges Open-Source-Projekt, wurde aber 2020 von Microsoft übernommen. Es hat technisch zwei Teile: den eigentlichen Paketmanager selbst; und das Paket-Repository, eine ständig wachsende Liste von *fast zwei Millionen* verfügbaren Paketen zur Installation.
Sie können sich npm als den App Store für alles vorstellen, was Sie für ein Frontend- oder Node-basiertes Projekt verwenden möchten. Finden Sie, was Sie wollen, und installieren Sie es über die Befehlszeile auf Ihrem System. Sie können dieses Paket aktualisieren, wenn eine neue Version veröffentlicht wird, oder es ganz löschen, wenn das Projekt es nicht mehr benötigt.
Ein Hinweis zu npx
Sie sehen vielleicht *auch* npx-Befehle. npx ist tatsächlich Teil von npm, aber durch die Verwendung von npx anstelle von npm in einem Befehl können Sie den Code eines Pakets *ausführen, ohne es *dauerhaft* *zu installieren*. NPX installiert nur, was es braucht, führt es aus und verwirft es.
Das ist hilfreich, wenn Sie zum Beispiel ein Installationsskript ausführen möchten. Anstatt den Installer herunterzuladen, *dann* ihn auszuführen, lässt npx Sie den Installer einfach direkt ausführen, ohne danach etwas auf Ihrem Computer zu hinterlassen. Es ist wie der Hausgast, der nach sich selbst aufräumt.
Ein weiteres cooles Beispiel: Sie könnten npx sass (zusammen mit den notwendigen Eingabe- und Ausgabeargumenten) ausführen, wenn Sie die Sass-Dateien Ihres Projekts nur einmal kompilieren möchten, ohne den Aufwand einer vollständigen Sass-Installation. Dies ist in den meisten Fällen wahrscheinlich nicht praktikabel, aber wenn Sie nur hier und da eine schnelle einmalige Kompilierung benötigen, wäre npx ein praktischer Weg dazu, da es weniger installierte Pakete gibt, die aktualisiert und gewartet werden müssen.
Was kommt als Nächstes
Okay, das war ein tiefer Einblick in das, was wir meinen, wenn wir etwas als Paketmanager bezeichnen. Im Fall von npm wird es speziell zum Installieren und Verwalten von Node-Paketen verwendet, Werkzeuge, die dazu beitragen, einem Projekt Funktionen hinzuzufügen, praktische Entwicklerannehmlichkeiten hinzuzufügen … oder all das oben Genannte!
Als Nächstes machen wir den ersten Schritt zur *Verwendung* von npm. Und dafür müssen wir es auf unserem System installieren. Das ist der nächste Punkt in diesem vollständigen Leitfaden zu npm.