JavaScript-Paketmanager pnpm vermeidet doppelte Packages
Der als Alternative zu npm und Yarn ausgelegte Paketmanager setzt auf ein Content-Addresseable Filesystem, um bei Updates nur veränderte Packages zu übernehmen.
(Bild: Nice to meet you / Shutterstock.com)
- Rainald Menge-Sonnentag
Der Paketmanager für JavaScript pnpm ist in Version 5.0 erschienen. Er lässt sich als Alternative zu npm und Yarn verwenden und ist vor allem für Monorepos optimiert. Im Gegensatz zu den anderen Paketmanagern setzt er nicht auf eine flache Struktur, sondern gruppiert die Pakete mit ihren Dependencies. pnpm 5 optimiert das Speichern von Dateien und reduziert das Verschachteln der Verzeichnisse.
Außerdem haben die Entwickler an der Performance geschraubt. Laut den Benchmarks des pnpm-Teams bietet das aktuelle Release um ein Drittel schnellere Installationszeiten als die im Oktober 2019 veröffentlichte Version 4.0 des Paketmanagers.
Harte Verweise
pnpm 5 setzt auf ein nach dem Prinzip von Content-Addressed Storage (CAS) aufgebautes Content-Addressable Filesystem zum Speichern der Pakete. Als Vorlage dient der CAS von Git und das Deduplikations-Werkzeug Dupe krill. Für Dateien mit identischem Inhalt speichert der Paketmanager lediglich Hardlinks.
Als Beispiel dient in den Release Notes ein Update der JavaScript Library Lodash: Wenn bei einer Aktualisierung lediglich eine von 100 Dateien einen geänderten Inhalt hat, fügt pnpm nur diese eine Datei den verwalteten Paketen hinzu. Details zur Umsetzung des Content-Addressable Filesystem finden sich im zugehörigen Issue auf GitHub.
Weniger verschachtelt
Der Paketmanager vereinfacht zudem die Verzeichnisstruktur des Virtual Store, die nun weniger verschachtelt ist. Die Release Notes führen als Beispiel das Installieren einer Datei foo@1.0.0 an, die pnpm 4 als Hardlink zu node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/ abgelegt hat. Bei pnpm 5 ist der Ort stattdessen node_modules/.pnpm/foo@1.0.0/.
Außerdem sperrt pnpm keine Verzeichnisse mehr, da der Directory-Lock wohl auf einigen Systemen Probleme bereitet hat. Mit der Sperre ist auch der Parameter --no-lock verschwunden, der nun zu einer Fehlermeldung führt.
Mit Version 5 verschwinden ebenfalls die Einstellungen resolution-strategy und independent-leaves. Letztere für Symlinks aus Dependencies hat keine Zukunft, und erstere ist standardmäßig auf fewer-depencies gesetzt. Die zuvor daneben verfügbare fast-Option verträgt sich wohl nicht mit künftigen Plänen zum Verbessern des Algorithmus.
Weitere Neuerungen und Änderungen in pnpm 5 lassen sich den Release Notes auf GitHub entnehmen. Der Sourcecode steht im Repository unter MIT-Lizenz bereit. (rme)
