Solltest du von npm zu pnpm wechseln?

May 26, 2026 · 5 min read

Du hast pnpm wahrscheinlich schon in Monorepo-Setups, CI-Konfigurationen und Framework-Dokumentationen gesehen. Vielleicht schwört eine Kollegin oder ein Kollege darauf. Aber lohnt sich der Wechsel tatsächlich für deine tägliche Frontend-Arbeit, oder löst er Probleme, die du noch gar nicht hast?

Hier ist, was du wirklich wissen musst.

Wichtige Erkenntnisse

pnpm verwendet einen content-addressable Store mit Hard Links und Symlinks, eliminiert Phantom Dependencies und reduziert den Speicherverbrauch über mehrere Projekte hinweg.
pnpm 11 setzt die in pnpm 10 eingeführten Einschränkungen für Lifecycle-Skripte fort und erfordert eine explizite Freigabe via pnpm approve-builds, um Supply-Chain-Risiken zu reduzieren.
Workspace-Filterung und das workspace:*-Protokoll machen pnpm zur starken Wahl für Monorepos mit Turborepo oder Nx.
Fixiere deinen Paketmanager über das packageManager-Feld in package.json und nutze --frozen-lockfile in CI für deterministische Installationen.
pnpm glänzt in Monorepos und Multi-Projekt-Setups; für eine Single-Package-App ist es oft völlig ausreichend, bei npm zu bleiben.

Was pnpm von npm unterscheidet

pnpm ist nicht einfach nur ein schnelleres npm. Die echten Unterschiede sind struktureller Natur.

npm erstellt ein flaches node_modules-Verzeichnis, was bedeutet, dass dein Code versehentlich Pakete importieren kann, die du nie als Dependency deklariert hast – ein Problem, das als Phantom Dependencies bekannt ist. pnpm verwendet einen content-addressable Store mit Hard Links und Symlinks, sodass nur deine deklarierten Dependencies auf Root-Ebene zugänglich sind. Das macht die Dependency-Auflösung strenger und reproduzierbarer.

Der andere wesentliche Unterschied ist der Speicherverbrauch. pnpm speichert jede Paketversion einmal global und verlinkt sie per Hard Link in deine Projekte. Wenn du mehrere Next.js- oder Vite-Projekte lokal pflegst, werden nicht Hunderte von Megabyte pro Projekt dupliziert.

Für eine detailliertere Aufschlüsselung des Speichermodells und der Dependency-Isolation lohnt sich ein Blick in den offiziellen pnpm vs npm Vergleich.

pnpm 11 und der Security-First-Shift

pnpm 11, veröffentlicht im April 2026, setzt einen Trend fort, der sich über die letzten Major-Versionen hinweg aufgebaut hat: Sicherheit und Determinismus haben Vorrang vor reiner Geschwindigkeit.

Das wichtigste Verhalten, das du vor dem Wechsel kennen solltest: pnpm blockiert Lifecycle-Skripte von Dependencies standardmäßig, sofern sie nicht explizit freigegeben werden. Das ist der in pnpm 10 eingeführte pnpm approve-builds-Workflow. Wenn du ein Paket mit einem postinstall-Skript installierst – üblich bei Paketen, die native Binaries kompilieren, wie sharp, esbuild oder canvas –, wird die Installation erfolgreich abgeschlossen, aber das Skript wird erst ausgeführt, wenn du es freigibst.

Das überrascht Entwickler, die erwarten, dass einfach alles funktioniert. Führe pnpm approve-builds interaktiv aus oder konfiguriere erlaubte Build-Dependencies in pnpm-workspace.yaml:

onlyBuiltDependencies:
  - sharp
  - esbuild

Es ist ein bewusster Kompromiss: mehr Reibung im Voraus, dafür weniger Supply-Chain-Überraschungen später.

Workspaces und Monorepo-Tooling

Hier zieht pnpm spürbar davon. npm-Workspaces funktionieren zwar, aber pnpms Workspace-Implementierung ist für größere Setups deutlich ergonomischer.

Du definierst Pakete in einer pnpm-workspace.yaml-Datei:

packages:
  - 'apps/*'
  - 'packages/*'

Und bekommst direkt leistungsstarke Filteroptionen out of the box:

pnpm --filter @myapp/ui build
pnpm --filter "...^@myapp/ui" test  # führt Tests in Paketen aus, die von ui abhängen

Für Teams, die Turborepo oder Nx einsetzen, integriert sich pnpms Workspace-Protokoll (workspace:*) sauber und hält interne Dependencies explizit.

Versionen mit dem packageManager-Feld fixieren

Ein praktischer Schritt, unabhängig davon, ob du Corepack nutzt: Füge ein packageManager-Feld zu deiner package.json hinzu, um zu signalisieren, welchen Paketmanager und welche Version dein Projekt erwartet.

{
  "packageManager": "pnpm@11.0.0"
}

Corepack kann das in entsprechend konfigurierten Umgebungen erzwingen, aber selbst ohne Corepack kommuniziert es die Absicht klar an dein Team und dein CI-Setup.

CI-Integration mit GitHub Actions

- uses: pnpm/action-setup@v6
  with:
    version: 11
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'
- run: pnpm install --frozen-lockfile

Nutze in CI immer --frozen-lockfile. Das verhindert stille Lockfile-Mutationen und macht Installationen deterministisch.

Die offizielle pnpm CI-Dokumentation enthält auch Beispiele für GitHub Actions, GitLab CI, CircleCI, Azure Pipelines und Bitbucket Pipelines.

Wann sich der Wechsel lohnt

pnpm ergibt am meisten Sinn, wenn du in einem Monorepo arbeitest, viele lokale Projekte verwaltest oder standardmäßig eine striktere Dependency-Isolation möchtest. Das pnpm approve-builds-Sicherheitsmodell ist tatsächlich nützlich für Teams, denen Supply-Chain-Hygiene wichtig ist.

Wenn du eine Single-Package-App pflegst und npm gut funktioniert, ist die Migrationsreibung wahrscheinlich den Aufwand nicht wert. npm-Workspaces sind reif genug für unkomplizierte Setups, und der ökosystemweite Default hat nach wie vor seinen Wert.

Fazit

Die ehrliche Antwort: Probiere pnpm zuerst in einem neuen Projekt aus. Die Kommando-Oberfläche ist nahezu identisch, das Lockfile ist lesbar, und die meisten Frontend-Frameworks – darunter Next.js, Vite und Astro – unterstützen es ohne zusätzliche Konfiguration. Wenn die Strenge und die Speicherersparnis zu deinem Workflow passen, wird die Skalierung auf bestehende Projekte zu einer deutlich kleineren Entscheidung.

FAQs

In der Regel ja. Lösche node_modules und package-lock.json, führe dann pnpm import aus, um dein Lockfile zu konvertieren, gefolgt von pnpm install. Achte auf Phantom Dependencies, auf die sich dein Code unter npms flachem Layout möglicherweise verlassen hat – pnpm bringt sie als fehlende Imports zum Vorschein, die du behebst, indem du sie explizit zur package.json hinzufügst.

approve-builds ist eine Allowlist von Paketen, denen erlaubt ist, Lifecycle-Skripte auszuführen. Du kannst das Gate komplett deaktivieren, aber damit holst du dir das Supply-Chain-Risiko zurück, das pnpm 11 gerade entschärfen soll. Der empfohlene Weg ist, nur Paketen die Freigabe zu erteilen, denen du vertraust und die wirklich postinstall-Schritte benötigen, wie etwa Compiler für native Binaries.

Die große Mehrheit funktioniert ohne Anpassungen. Probleme treten meist bei Paketen auf, die eine flache node_modules-Struktur voraussetzen oder sich auf Phantom Dependencies verlassen. Die meisten populären Libraries haben das längst behoben. Falls etwas nicht funktioniert, kann die public-hoist-pattern-Einstellung in .npmrc als Notausgang ein npm-ähnliches Hoisting für bestimmte Pakete nachbilden.

Bei Cold Installs ist pnpm typischerweise schneller, dank paralleler Auflösung und content-addressable Store. Bei Warm Installs über Projekte hinweg, die sich Dependencies teilen, ist der Unterschied dramatisch, weil pnpm bereits heruntergeladene Pakete über Hard Links wiederverwendet. In CI mit gefülltem Cache verringert sich der Abstand, aber pnpm behält in der Regel die Nase vorn.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.