
What Is a Lockfile? Reproducible Installs, Explained (package-lock, Cargo.lock and more)
- VersionDude
- guides
- 7 Min. Lesezeit
A lockfile records the exact resolved version of every dependency so everyone installs the same thing. Why manifests alone are not enough, how integrity hashes add security, and whether to commit it.
Eine lockfile ist eine Datei, die dein Paketmanager schreibt, um die exakten Versionen jeder Abhaengigkeit festzuhalten, die dein Projekt installiert hat - nicht nur die, die du angefordert hast, sondern auch die Abhaengigkeiten dieser Abhaengigkeiten. Ihr ganzer Zweck ist Reproduzierbarkeit: Sie stellt sicher, dass du, dein Teamkollege und dein Produktionsserver alle Byte fuer Byte denselben Satz an Paketen installieren, statt einfach dem, was zum Installationszeitpunkt zufaellig am neuesten ist. Falls du jemals eine package-lock.json, yarn.lock oder Cargo.lock gesehen und dich gefragt hast, wofuer sie da ist, das ist die Antwort.
Um zu verstehen, warum das wichtig ist, musst du dir ansehen, was dein Manifest tatsaechlich aussagt. Eine Datei wie package.json fixiert Abhaengigkeiten meist als Versionsbereiche, nicht als exakte Versionen - zum Beispiel ^1.2.3, was unter SemVer jede Veroeffentlichung von 1.2.3 bis ausschliesslich 2.0.0 bedeutet. Diese Flexibilitaet ist nuetzlich, hat aber einen Nachteil: Installierst du das Projekt heute, bekommst du vielleicht 1.2.4, installierst du es naechsten Monat, vielleicht 1.2.9. Gleiches Manifest, anderer tatsaechlicher Code.
Die lockfile schliesst diese Luecke. Bei der ersten Installation loest der Paketmanager all diese Bereiche in konkrete Versionen auf und schreibt sie zusammen mit einem Integritats-Hash fuer jedes Paket in die lockfile. Von da an liest jeder, der installiert, die lockfile und erhaelt genau diese exakten Versionen - nicht den Bereich, sondern die spezifische aufgeloeste Version. Das Ergebnis ist jedes Mal eine deterministische, reproduzierbare Installation, was eine ganze Klasse von 'aber auf meinem Rechner laeuft es'-Fehlern beseitigt.
Dieser Integritats-Hash erfuellt eine zweite wichtige Aufgabe. Jeder Eintrag in der lockfile speichert eine Pruefsumme des Paketinhalts, sodass der Paketmanager beim Herunterladen einer Abhaengigkeit pruefen kann, ob die Bytes mit dem uebereinstimmen, was gesperrt wurde. Wuerde ein Paket in der Registry manipuliert, wuerde der Hash nicht passen und die Installation schlaege fehl. In einer Zeit von Supply-Chain-Angriffen ist diese Pruefung ein stiller, aber echter Sicherheitsvorteil.
Jedes Oekosystem hat seine eigene Variante derselben Idee. In JavaScript gibt es package-lock.json (npm), yarn.lock (Yarn) und pnpm-lock.yaml (pnpm); in Rust Cargo.lock; in Python poetry.lock und uv.lock; in Ruby Gemfile.lock; in PHP composer.lock. Das Dateiformat unterscheidet sich, aber die Aufgabe ist identisch: den exakt aufgeloesten Abhaengigkeitsbaum festhalten, damit er sich exakt reproduzieren laesst.
Eine haeufige Frage ist, ob du die lockfile in die Versionskontrolle aufnehmen solltest. Fuer Anwendungen ja - du willst, dass deine Deployments genau die Versionen installieren, die du getestet hast, also gehoert die lockfile ins Repository. Fuer Bibliotheken ist die Konvention anders: Viele Bibliotheksautoren committen keine lockfile, weil die Projekte, die von der Bibliothek abhaengen, ohnehin ihre eigenen Versionen aufloesen und sperren.
Die lockfile und das Manifest sind ein Team, keine Rivalen. Das Manifest drueckt die Absicht mit SemVer-Bereichen aus - 'ich will eine kompatible 1.x dieses Pakets' - was dich fuer sichere Updates offen haelt. Die lockfile haelt die Realitaet fest - 'genau diese Version verwenden wir tatsaechlich' - was Installationen reproduzierbar haelt. Wenn du die Details der Bereiche selbst willst, sieh dir unseren Leitfaden zu SemVer an.
Wie die lockfile aktualisiert wird, haengt vom Befehl ab, den du ausfuehrst. Eine einfache Installation (wie npm install) kann die lockfile aktualisieren, wenn sie neuere, von deinen Bereichen noch erlaubte Versionen findet. Eine strikte, reproduzierbare Installation (wie npm ci) ignoriert die Bereiche voellig und installiert exakt das, was die lockfile vorgibt, und schlaegt fehl, falls beide nicht uebereinstimmen - was du bei CI und Produktions-Builds genau willst.
Ein paar praktische Gewohnheiten machen lockfiles schmerzlos. Bearbeite sie nicht von Hand; lass das Werkzeug sie neu erzeugen. Wenn du einen Merge-Konflikt in einer lockfile bekommst - was passiert, weil zwei Branches Abhaengigkeiten hinzugefuegt haben - loese ihn, indem du die Installation erneut ausfuehrst, statt die Datei von Hand zu bearbeiten. Und committe die lockfile bei einer Anwendung immer, damit die Version, die alle bauen, die Version ist, die du tatsaechlich getestet hast.


