Startseite / Artikel / Neun Node.js-Hilfspakete, die es lohnt, vor dem Programmieren hinzuzufügen

Node.js TypeScript JavaScript DevTools Backend

Neun Node.js-Hilfspakete, die es lohnt, vor dem Programmieren hinzuzufügen

Erfahren Sie, wie eine kleine Anzahl von Node.js-Paketen – die Umgebungskonfiguration, Validierung, Skripting, Prozessverwaltung und Protokollierung abdecken – häufige Fehler frühzeitig beseitigen können.

1381 Wörter

Jedes neue Node-Projekt folgt in der Regel dem gleichen Muster: ein leeres Verzeichnis, eine einzige Datei index.js sowie der naive Glaube, dass die Standardbibliothek den größten Teil dessen abdeckt, was man benötigt. Schon nach ein paar Tagen muss man eigene Wiederholungsschleifen per Hand schreiben, Daten mit regulären Ausdrücken parsen und erneut einen leicht abgewandelten .env-Lader entwickeln.

Irgendwann macht es Sinn, auf das ständige Erfinden neuer Lösungen zu verzichten und stattdessen vor dem Schreiben eigener Logik auf ein kleines, konsistentes Werkzeugset zurückzugreifen. Keines dieser Pakete ist besonders auffällig – jedes beseitigt still und heimlich eine bestimmte Kategorie von Fehlern, die oft als unvermeidlicher Kostenfaktor bei der Softwareentwicklung hingenommen wird. Hier sind neun Pakete, die man frühzeitig in jedem Projekt installieren sollte.

1. dotenv

Falls Sie jemals versehentlich einen API-Schlüssel in ein Git-Repository eingefügt haben, verstehen Sie bereits den Reiz dieses Pakets. dotenv lädt Schlüssel-Wert-Paare aus einer .env-Datei in process.env hoch, wodurch sensible Daten in einer Datei gespeichert werden, die außerhalb des Versionskontrollsystems bleibt, anstatt direkt im Code enthalten zu sein.

// .env
DATABASE_URL=postgres://localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_...

// index.js
import "dotenv/config";
const db = connect(process.env.DATABASE_URL);

Es handelt sich um ein minimalistisches Paket mit einer begrenzten Aufgabe, doch es macht den Unterschied aus, ob alle Konfigurationen an einem vorhersehbaren Ort liegen oder über mehrere Dateien verteilt sind sowie ob eine Nachricht in einem alten Chat-Thread versteckt ist.

2. zod

Die Validierung von Schemata zur Laufzeit wird leicht unterschätzt, wenn ein paar if-Anweisungen scheinbar ausreichen. Dieses Vertrauen verschwindet in der Regel sofort, sobald eine fehlerhafte Anfrage diesen Überprüfungen entgeht und in die Produktion gelangt.

zod ermöglicht es Ihnen, die Struktur der Daten einmalig zu definieren und daraus sowohl einen Validierer zur Laufzeit als auch den entsprechenden TypeScript-Typ abzuleiten:

import { z } from "zod";

const CreateUserSchema = z.object({
  email: z.string().email(),
  age: z.number().min(13),
});type CreateUser = z.infer<typeof CreateUserSchema>;app.post("/users", (req, res) => {
  const result = CreateUserSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ error: result.error.flatten() });
  }
  // result.data is now typed and validated
  createUser(result.data);
});

Der größte Vorteil zeigt sich an den Grenzen Ihrer Anwendung: eingehende API-Daten, Umgebungsvariablen, Konfigurationsdateien sowie überall sonst, wo Daten in Ihr System gelangen. Die Validierung an diesen Eingangspunkten bedeutet, dass der Rest Ihres Codes sicher davon ausgehen kann, dass die empfangenen Daten die erwartete Struktur aufweisen.

3. tsx

Jeder, der TypeScript verwendet, ist vermutlich bereits mit den Aufwand durch das Ausführen eines einzelnen Skripts konfrontiert worden: Kompilieren mit tsc vor dem Ausführen des Ergebnisses oder das Einrichten von ts-node und das Warten auf dessen Startzeit. tsx beseitigt diesen Aufwand vollständig, indem es .ts-Dateien direkt ausführt – ohne Build-Schritt und ohne zusätzliche Konfiguration.

tsx scripts/migrate-users.ts

Es ist nicht dafür konzipiert, einen Produktions-Build-Pipeline zu ersetzen. Es wurde für die Dutzenden kleiner Skripte entwickelt, die sich im Laufe der Zeit in jeder Codebasis ansammeln – wie einmalige Migrationsvorgänge, Seed-Skripte oder schnelle Datenprüfungen. Für diese Fälle ist keine vollständige Build-Einrichtung notwendig; sie müssen lediglich nahezu sofort ausgeführt werden, damit man nicht durch das Warten auf einen Compiler den Überblick verliert.

4. execa

Die eingebaute child_process-Modul von Node erledigt die Aufgabe, doch ihre korrekte Verwendung bedeutet, jedes Mal manuell stdout, stderr, Exit-Codes und Fehler handhaben zu müssen. execa bündelt all das in eine Schnittstelle, die genauso funktioniert, wie man es erwarten würde:

import { execa } from "execa";

const { stdout } = await execa("git", ["rev-parse", "--short", "HEAD"]);
console.log(`Current commit: ${stdout}`);

Fehler werden wie vorgesehen ausgeworfen, anstatt stillschweigend zu versagen. Die Ausgabe wird automatisch gekürzt, und die Unterstützung für async/await ist bereits integriert – es ist nicht notwendig, eigene Promise-Wrapper um spawn zu schreiben. Für alle, die CLI-Tools oder Skripte entwickeln, die auf andere Programme zugreifen, beseitigt dieses Paket eine ganze Klasse von Fehlern, bei denen etwas stillschweigend nichts tut und man raten muss, warum.

5. p-retry

Netzwerke sind unzuverlässig. APIs setzen Rate Limits. Datenbankverbindungen brechen manchmal aus Gründen ab, die nie vollständig erklärt werden. p-retry umhüllt jede asynchrone Funktion mit einer Wiederholungslogik und exponentiellem Backoff, sodass ein fehleranfälliger Aufruf den gesamten Prozess nicht lahmlegt:

import pRetry from "p-retry";

const data = await pRetry(() => fetchFromFlakyApi(url), {
  retries: 5,
  onFailedAttempt: (error) => {
    console.log(`Attempt ${error.attemptNumber} failed. Retrying...`);
  },
});

Es ist üblich, dass man für jedes Projekt diese Art von Logik manuell schreiben muss – meist mit Fehlern und oft ohne angemessene Wartezeiten. Dadurch kann eine bereits überlastete API durch schnelle Neuanläufe noch stärker belastet werden. Dieses Paket erledigt die Aufgabe korrekt in nur wenigen Zeilen und hat dadurch verhindert, dass mehr als eine Integration während eines regulären Ausfalls eines Drittanbieterdienstes völlig versagt hat.

6. day.js

Die Arbeit mit Datumsangaben in reinem JavaScript ist äußerst umständlich. moment.js, die Bibliothek, auf die sich die meisten Menschen zunächst verlassen, ist außerdem sehr ressourcenintensiv und wird nicht mehr aktiv weiterentwickelt. day.js bietet eine ähnlich benutzerfreundliche API, ist dabei aber deutlich kompakter:

import dayjs from "dayjs";

const deadline = dayjs().add(3, "day").format("YYYY-MM-DD");
const isOverdue = dayjs(invoice.dueDate).isBefore(dayjs());

Das Formatieren von Datumsangaben, das Vergleichen derselben, das Hinzufügen oder Subtrahieren von Zeitintervallen sowie die Analyse unstrukturierter Datumszeichenfolgen werden alle einfacher – dadurch entstehen keine feinen Fehler durch eine falsche Berechnung um einen Tag, die bei manueller Ausführung dieser Arithmetik auftreten können.

7. pino

console.log eignet sich gut für kleine Skripte, doch wenn Sie einen Produktivdienst betreiben, der täglich Tausende von Protokolleinträgen erzeugt, benötigen Sie eine Lösung, mit der Sie diese tatsächlich filtern und suchen können. pino liefert strukturierte JSON-Protokolle in einer Geschwindigkeit, die fast keinen messbaren Einfluss auf Ihre Anwendung hat:

import pino from "pino";
const logger = pino();

logger.info({ userId: user.id, action: "checkout" }, "Order placed");

Weil die Ausgabe strukturiert ist, kann jedes Tool, das sie verarbeitet – sei es Datadog, ein ELK-Stack oder sogar später das Durchsuchen einer Datei mit grep – sie ordnungsgemäß parsen und filtern. Das ist besser, als durch Seiten voller Plain-Text scrollen zu müssen, um in einer Notlage die relevante Zeile zu finden.

8. cheerio

Mannchmal reicht es aus, nur einen Teil strukturierter Daten von einer HTML-Seite zu extrahieren, und das Starten eines vollständigen headless-Browsers erscheint für eine Aufgabe, die im Grunde nur darin besteht, „dieses Element zu finden und seinen Text zu lesen“, als übermäßig. cheerio bietet eine jquery-ähnliche API zum Parsen und Abfragen von HTML auf Serverseite – ohne die Kosten des Startens eines echten Browsers:

import * as cheerio from "cheerio";

const $ = cheerio.load(html);
const titles = $("h2.product-title")
  .map((_, el) => $(el).text().trim())
  .get();

Es führt keine JavaScript-Code aus, sodass es nicht als Ersatz für Tools wie Playwright dienen kann, wenn der Inhalt clientseitig gerendert wird. Für das Scannen statischer Markup-Strukturen, die Verarbeitung feedähnlichen Inhalts oder das Extrahieren von Werten von von Ihnen kontrollierten Seiten ist es jedoch viel schneller und leichter als das Starten einer Browserinstanz.

9. pm2

Das Starten Ihrer Anwendung mit node index.js funktioniert einwandfrei – bis sie mitten in der Nacht abstürzt und nichts sie neu startet. pm2 hält Ihren Prozess am Laufen, startet ihn nach einem Absturz automatisch neu und bietet grundlegende Überwachung sowie Logverwaltung – alles ohne die Notwendigkeit einer vollständigen Container-Orchestrierungsplattform.

pm2 start index.js --name my-api
pm2 logs my-api
pm2 restart my-api

Für viele kleine und mittelgroße Umgebungen ist das tatsächlich die gesamte Prozessüberwachung, die man je benötigen wird. Es ersetzt Kubernetes nicht, wenn man ein großes verteiltes System verwalten muss, aber auf einem einzelnen Server mit ein paar Node-Prozessen macht es den Unterschied zwischen dem ständigen SSH-Einschalten, sobald etwas abstürzt, und dem vollständigen Fehlen dieses Problems von Anfang an.

Der eigentliche Punkt

Aus diesen neun Paketen ist keines für sich genommen besonders auffällig – und genau das ist die Botschaft. Jedes übernimmt einen kleinen Teil der Logik, den man sonst selbst schreiben müsste, wobei man beim ersten Versuch meist etwas falsch macht und anschließend unbegrenzt daran arbeiten muss. Das Verwenden dieser Pakete dient nicht dazu, Abkürzungen zu nehmen, sondern vielmehr dazu, die begrenzte Aufmerksamkeit auf die Teile der Anwendung zu richten, die man tatsächlich selbst entwickeln kann, anstatt für das fünfte Projekt wiederholt Schleifen neu zu implementieren und zu debuggen.