pnpm: eine Alternative zu npm

Was ist pnpm

pnpm ist eine Alternative zu den Paket-Managern npm oder yarn. Wie bei diesen Anbietern werden von pnpm die verwendeten Pakete von der npm-Registry gezogen. Der Unterschied liegt hauptsächlich in der Struktur des node_modules-Ordners. Während bei npm bzw. yarn die Pakete direkt in node_modules-Ordnern liegen, verwendet pnpm Hard- und Symlinks.

 

Weniger Speicherplatz

Die Verwendung von Hard- und Symlinks hat den Vorteil, dass jedes Paket pro Version nur einmal auf dem Computer gespeichert werden muss. Bei zehn Projekten, die alle React verwenden, wird i. d. R. mit npm sowohl React als auch sämtliche Abhängigkeiten zehnmal auf dem Rechner gespeichert – mit pnpm nur einmal.

 

Strikt

Möglicher Zugriff beim Verwenden von npm
Möglicher Zugriff beim Verwenden von npm

Pnpm ist strikt. Das bedeutet, der Entwickler kann nur die Pakete verwenden, die er explizit als Abhängigkeit angegeben habe. Hat er ein Paket A als Abhängigkeit, und dieses hat Paket B als Abhängigkeit, so kann er, wenn er npm verwendet, auf Methoden von Paket B zugreifen. Entfernt er Paket A, weil er es nichtmehr braucht, oder Paket A entfernt in einem Update Paket B als Abhängigkeit, dann wird sein Build fehlschlagen. Mit pnpm kann das nicht passieren, da man auf Paket B in diesem Fall nicht zugreifen kann.

 

npm als Fall back

Alle Befehle, die pnpm nicht kennt bzw. nicht implementiert hat, werden an npm übergeben. Für den Entwickler bedeutet das, dass er genauso arbeiten kann wie bisher. Alles was sich für ihn ändert, ist dass er ein p vor npm schreibt.

 

Schnell

pnpm ist schneller als npm und sogar yarn. Genauso wie yarn nutzt auch pnpm einen Cache. Allerdings ist bei yarn der Algorithmus zur Bestimmung des flachen node_moudles-Ordners komplizierter, deshalb ist pnpm schneller.

 

Deterministisch

Im Gegensatz zu npm ist pnpm (genauso wie yarn) deterministisch. Das bedeutet, dass das Installieren im Projekt auf verschiedenen Maschinen zu verschiedenen Zeitpunkten das gleiche Ergebnis liefern wird. Erreicht wird das durch die pnpm-lock.yaml, die mit in die Codeverwaltung eingecheckt wird.

 

Verschiedene Versionen der Abhängigkeiten

Konflikt beim Auflösen von Versionen für npm
Konflikt beim Auflösen von Versionen für npm

In früheren Versionen von npm wurden die Abhängigkeiten eines Pakets in dessen Ordner abgelegt. Bei Abhängigkeiten von Abhängigkeiten führte das zu sehr langen Pfaden, die unter Windows zu Problemen führten. Aufgrund dessen erstellen npm und yarn einen „flachen“ noce_modules-Ordner. Um Speicherplatz zu sparen, wird ermittelt, welche Version verwendet werden sollte, sodass möglichst viele Pakete, die dieses Paket verwenden, die richtige Version haben. Solange sich alle an die semantische Versionierung halten bzw. rückwärtskompatibel sind, ist das gut. Leider ist das nicht immer der Fall. Das allein ist sicher kein Grund auf pnpm zu wechseln, aber soll hier nicht unerwähnt bleiben.

 

Zusammenfassung

Für Entwickler ist die Umstellung auf pnpm sehr einfach. Sie müssen nur vor jeden npm-Befehl ein „p“ schreiben. Anschließend müssen noch einmal mögliche versteckte Abhängigkeiten aufgeräumt werden. Das ist aber absolut sinnvoll, denn diese könnten später zu nicht bedachten Fehlern führen.
Allerdings sollten auch mögliche Build-Pipelines angepasst werden. Hier ist der Support zumindest in Azure DevOps noch sehr gering: Für npm gibt es fertige Befehle, für pnpm nicht. Zudem ist pnpm leider nicht so weit verbreitet. Bei Problemen fragt beispielsweise Google, ob man sich nicht verschrieben habe und „npm“ meine.

 

Persönliches Fazit

Für mich persönlich sind vor allem die Striktheit sowie die effektivere Speicherplatznutzung von pnpm gute Gründe umzusteigen. Da die Umstellung zudem noch sehr einfach ist, kann ich pnpm nur empfehlen.

 

Quellen

pnpm.js.org/

www.npmjs.com/

yarnpkg.com/