Pakete installieren

Bis hierhin hast du alles selbst geschrieben oder aus Node genommen. Jetzt kommt fremder Code dazu, und das ist die größte Stärke des Ökosystems und zugleich die Stelle, an der die meisten Sicherheitsvorfälle passieren. Beides gehört in denselben Abschnitt.

01 / 05Was ein npm install anrichtet

Der Befehl ist kurz:

npm install slugify

Danach sind drei Dinge anders. In der package.json steht ein neuer Eintrag unter dependencies. Im Ordner node_modules liegt das Paket samt allem, was es selbst braucht. Und in der package-lock.json steht, welche Version genau geholt wurde, mitsamt Prüfsumme.

{
  "name": "titel-werkzeug",
  "version": "1.0.0",
  "type": "module",
  "private": true,
  "dependencies": {
    "slugify": "^1.6.9"
  },
  "devDependencies": {
    "vitest": "^4.1.10"
  }
}

Von den drei Dingen gehört genau eins ins Repository, und welches das ist, klärt Lektion 5.4. Vorweg so viel: node_modules ist es nicht.

Auf dieser Maschine sieht es an einer Stelle anders aus, und du solltest wissen warum. Die Sandbox hat kein Netz. Die beiden Pakete, die dieser Kurs benutzt, liegen deshalb schon bereit und werden nur nach node_modules kopiert, statt geholt zu werden. Von den drei Dingen oben passiert hier also nur eines: Das Paket liegt da, in deiner package.json steht nichts davon, und eine package-lock.json gibt es gar nicht.

Sieh es dir an. Starte die Sandbox, hol die Aufgabe dieser Lektion nach vorn und tipp im Terminal ls node_modules, dann steht dort slugify. Tipp npm ls, und npm nennt dasselbe Paket extraneous: Es liegt da, ohne dass die package.json es verlangt hätte. Genau diesen Eintrag schriebe npm install slugify auf deinem Rechner mit hinein. Und wenn du es hier mit einem anderen Paket versuchst, etwa npm install lodash, endet das mit npm error code EAI_AGAIN, derselben Ursache wie der fehlgeschlagene Zugriff aus Lektion 1.5.

02 / 05Die zwei Listen

Im Beispiel siehst du zwei Blöcke, und der Unterschied zwischen ihnen ist eine einzige Frage:

Braucht der laufende Code das Paket, oder brauchst nur du es beim Entwickeln?

slugify wird zur Laufzeit importiert. Ohne das Paket läuft dein Programm nicht. Also dependencies.

vitest führt deine Tests aus. Auf dem Server läuft es nie. Also devDependencies, und das schreibst du mit npm install --save-dev vitest oder kurz npm i -D vitest.

Testwerkzeuge, Linter, Formatierer, Bündler und Typdefinitionen gehören in die zweite Liste. Alles, was in einem import deines Programms auftaucht, in die erste.

03 / 05Warum die Unterscheidung auf dem Server zählt

Auf deinem Rechner merkst du keinen Unterschied, npm install holt beide Listen.

Auf einem Server läuft aber meistens dieser Befehl:

npm ci --omit=dev

Das lädt nur die dependencies. Testwerkzeuge, die dort nie gebraucht werden, wandern gar nicht erst über die Leitung. Das spart Zeit bei jedem Deployment und verkleinert die Angriffsfläche, denn jedes Paket auf dem Server ist Code, der dort laufen kann.

Der Haken: Steht etwas in der falschen Liste, fehlt es dann. Und zwar nicht beim Installieren, sondern beim ersten Start, mit einem ERR_MODULE_NOT_FOUND für ein Paket, das auf deinem Rechner seit Wochen da ist. Das ist die zweithäufigste Fassung von „bei mir läuft es”.

04 / 05Ein Paket benutzen heißt, seine Dokumentation lesen

Jetzt der Teil, der beim Installieren gern übersprungen wird.

import slugify from "slugify";

const titel = "Grüße aus Köln";

console.log("Ohne Optionen:", slugify(titel));
console.log("Klein:        ", slugify(titel, { lower: true }));
console.log("Mit locale de:", slugify(titel, { lower: true, locale: "de" }));

Dreimal dasselbe Paket, dreimal derselbe Titel, drei verschiedene Ergebnisse.

Ohne Optionen bleibt die Großschreibung stehen. Mit lower: true wird alles klein. Und aus dem ü wird in beiden Fällen ein schlichtes u: grusse-aus-koln.

Für einen deutschen Text ist das falsch. ü wird im Deutschen zu ue, ß zu ss. Genau dafür gibt es locale: "de", und erst damit kommt gruesse-aus-koeln heraus. Nebenbei wird aus dem & dann auch ein und statt eines and.

Die Vorgabe eines Pakets ist nicht automatisch die richtige Einstellung für dich. Sie ist die, die dem Autor am sinnvollsten schien, und der schreibt selten auf Deutsch. Zwei Minuten in der README hätten das gezeigt, und ohne sie stehen später ein paar tausend falsche Adressen in deiner Datenbank.

05 / 05npx, wenn du es nur einmal brauchst

Manche Werkzeuge willst du benutzen, aber nicht aufnehmen. Ein Projektgerüst erzeugen, einmal einen Code prüfen, eine Datei umwandeln.

npx <werkzeug> holt das Paket, führt es aus und nimmt es nicht in dein Projekt auf.

Praktisch, und mit einem Vorbehalt: Was du dir da holst, hat niemand angeschaut. Bei npx fällt der Moment weg, in dem du normalerweise einen Blick auf das Paket wirfst. Genau darum geht es in Lektion 5.5.