pnpm 12.7 installiert mit --force keine Binärpakete anderer Plattformen mehr
Victoria Shinder2 Min. Lesezeitpnpm 12.7.0 ist am 25. September erschienen, parallel dazu 11.28.0 für die vorige Hauptversion. Die Änderung, die bestehende Projekte am ehesten betrifft, gilt pnpm install --force: Der Befehl überspringt jetzt weiterhin optionale Abhängigkeiten, deren Felder os, cpu oder libc nicht zum Rechner passen. Er lädt weiterhin alle Pakete neu und hebt engineStrict auf. Wer sich auf das alte Verhalten verlassen hat - unter --force optionale Binärpakete für alle Plattformen zu installieren -, stellt es mit der neuen Einstellung forceIgnoresPlatform wieder her.
Mehrere kleinere Funktionen kommen hinzu. Der globale node-Shim beachtet nun die nächstgelegene Datei .nvmrc oder .node-version, wenn ein Projekt keine Laufzeit in devEngines.runtime oder engines.runtime angibt; innerhalb eines Verzeichnisses gilt package.json vor .node-version vor .nvmrc, und Werte, mit denen nur nvm etwas anfangen kann, etwa system, werden ignoriert. pnpm install --allow-build erlaubt oder verbietet Lifecycle-Skripte eines Pakets über die Befehlszeile und hält die Entscheidung in pnpm-workspace.yaml fest. pnpm publish --publish-wait-timeout wartet, bis veröffentlichte Versionen und ihre Tarballs in der Registry verfügbar sind, und rekursives Veröffentlichen bestätigt jedes Paket, bevor abhängige Pakete folgen. Hat ein Repository ein Feld workspaces in der obersten package.json, aber keine pnpm-workspace.yaml, legt pnpm install die Datei an.
Die Release Notes nennen zudem drei Sicherheitskorrekturen: für Bin-Shims unter Nix, für Lifecycle-Skripte von Paketen in einem storeDir innerhalb des Workspace und für userAgent-Platzhalter in pnpm-workspace.yaml.
Was das bedeutet
Die Änderung an --force beseitigt eine Überraschung, die Teams im CI traf. --force wird oft eingesetzt, um eine beschädigte Installation zu bereinigen, und zog bisher zusätzlich native Binärpakete für jedes Betriebssystem und jede Architektur, die ein Paket unterstützt - größere und langsamere Installationen ohne Nutzen. Die neue Voreinstellung trifft, was meist gemeint ist; die Einstellung gibt es für den seltenen Fall, dass ein Paket für mehrere Plattformen auf einer Maschine gebaut wird.
Zwei der Funktionen zielen in dieselbe Richtung: Entscheidungen ausdrücklich und nachvollziehbar machen. Lifecycle-Skripte sind der Hauptweg, auf dem ein kompromittiertes Paket bei der Installation Code ausführt, und --allow-build macht ihre Freigabe zu einer geprüften Zeile in der Versionsverwaltung. Das Warten nach dem Veröffentlichen schließt eine stillere Lücke in Monorepos, in denen ein abhängiges Paket veröffentlicht werden konnte, bevor die Registry seine Abhängigkeit bereitstellte - mit einem kurzen Zeitfenster, in dem Installationen der neuen Version scheiterten.