Hvad er en lockfile?

Hvad en lockfile registrerer

Dit manifest, for eksempel package.json eller pyproject.toml, angiver de pakker, du er afhængig af, og de versionsintervaller, du accepterer. Pakkehåndteringen omsætter de intervaller til præcise versioner for hele træet, inklusive transitive afhængigheder, og skriver resultatet i lockfilen. npm's dokumentation siger, at package-lock.json beskriver "det præcise træ, der blev genereret, så efterfølgende installationer kan generere identiske træer".

En enkelt post i package-lock.json ser sådan ud:

"node_modules/raw-body": {
  "version": "3.0.0",
  "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-3.0.0.tgz",
  "integrity": "sha512-...",
  "dependencies": {
    "bytes": "3.1.2",
    "http-errors": "2.0.0",
    "iconv-lite": "0.6.3",
    "unpipe": "1.0.0"
  }
}

• version er den præcise version, der blev valgt.
• resolved er det sted, den blev hentet fra: en tarball-URL i et registry eller en git-URL med et commit.
• integrity er en Subresource Integrity-hash af tarballen, så en manipuleret download fejler.
• dependencies er dens egne afhængigheder, og det er sådan, træet, eller afhængighedsgrafen, bliver sat sammen.

Lockfiles efter pakkehåndtering

Pakkehåndtering	Lockfile	Installér uden at ændre den
npm	package-lock.json	npm ci
Yarn (Berry)	yarn.lock	yarn install --immutable
pnpm	pnpm-lock.yaml	pnpm install --frozen-lockfile
uv	uv.lock	uv sync --locked
Poetry	poetry.lock	poetry install
Cargo	Cargo.lock	cargo build --locked
Bundler	Gemfile.lock	bundle config set frozen true
Go modules	go.mod-versioner og go.sum-checksummer	Build-kommandoer opdaterer som standard ikke go.mod

Med almindelig pip er den gængse erstatning en requirements.txt med præcise versioner. Den fastlåser det, den angiver, men alt, hvad den udelader, bliver resolvet igen ved hver installation.

Brug frozen installs i CI

En lockfile hjælper kun, hvis buildet installerer fra den. En almindelig npm install kan opdatere package-lock.json, når den ikke længere stemmer overens med package.json, så buildet stille og roligt resolver et nyt træ. npm ci er bygget til automatiserede miljøer:

• Den kræver en package-lock.json eller npm-shrinkwrap.json.
• Hvis lockfilen og package.json ikke stemmer overens, afslutter den med en fejl i stedet for at opdatere låsen.
• Den fjerner først en eventuel eksisterende node_modules.
• Den skriver aldrig til package.json eller lockfilen.

De andre kommandoer i tabellen ovenfor gør det samme for deres pakkehåndteringer.

Applikationer og biblioteker

Commit lockfilen for applikationer og alt, hvad du deployer. For biblioteker låser den kun din egen udvikling og CI: npm udgiver aldrig package-lock.json og ignorerer den alle andre steder end i rodprojektet. De applikationer, der installerer dit bibliotek, resolver selv dets afhængigheder inden for dine versionsintervaller. Den ene undtagelse i npm er npm-shrinkwrap.json, som bliver udgivet og har forrang, og som de fleste biblioteker ikke bør bruge.

Derfor er en lockfile ikke en registrering af det leverede

En lockfile er planen for én pakkehåndtering i ét projekt. Det build, der producerede din release, gjorde mere end at følge den plan:

• Den er måske ikke blevet brugt. En installation uden frozen-tilstand, en manglende lockfile eller en anden lockfile i et monorepo betyder, at træet blev resolvet anderledes end i den fil, du kigger på.
• Caches. Pakker gendannet fra en CI-cache installeres uden at blive hentet, og en cache gendannet via en delvis nøgle kan være ældre end den aktuelle lockfile. Se hvad GitHub Actions-cachen skjuler.
• Build-værktøjer. Setup-actions, compilere, linters og kodegeneratorer kommer ad andre kanaler, med deres egne afhængighedstræer.
• Downloads og install-scripts. En curl i et build-trin eller en pakkes install-script henter kode, som ingen lockfile angiver.
• Base-images. Et container-build trækker images og styresystempakker, der ligger uden for enhver lockfile for et programmeringssprog.

Integrity-hashene hjælper ikke med noget af dette. De beviser, at pakkerne i lockfilen ikke er blevet manipuleret; de siger intet om, hvad buildet hentede uden for den. SCA-værktøjer, der omsætter en lockfile til en SBOM, arver de samme blinde vinkler.

Registrér buildet, behold lockfilen

Bliv ved med at committe lockfiles og installere fra dem med frozen installs. De gør builds gentagelige. Til registreringen af, hvad en release indeholder, registrerer CRACI selve buildet: En pakkebevidst proxy på dets GitHub Actions-runnere registrerer hver pakke, hvert job henter, inklusive pakker gendannet fra CI-caches, og hvert jobs SBOM angiver sin egen fuldstændighed. Den registrering giver et mere komplet billede af de afhængigheder, der er i brug, end en scanning af lockfilen. Se SBOM'er fra buildet, eller book en demo for at sammenligne de to på et af dine egne builds.

Lockfiles: ofte stillede spørgsmål

Hvad er en lockfile?

En lockfile er en fil, som en pakkehåndtering skriver for at registrere den præcise version af hver afhængighed, den har resolvet, direkte og transitive, sammen med, hvor den kom fra, og en checksum. Senere installationer læser den for at genskabe det samme træ i stedet for at resolve versionsintervaller igen.

Skal jeg committe min lockfile?

Ja, for applikationer og alt, hvad du deployer. Uden en committet lockfile resolver hver ny installation versionsintervaller igen og kan trække nye transitive versioner ind. Commit den, og installér fra den med en frozen install som npm ci i CI.

Fastlåser en lockfile transitive afhængigheder?

Ja. Det er dens hovedopgave. Manifestet angiver kun dine direkte afhængigheder og deres tilladte intervaller; lockfilen registrerer den præcise version, der blev valgt for hver pakke i træet.

Gælder lockfiles for biblioteker, jeg udgiver?

Ikke for dine brugere. npm udgiver for eksempel aldrig package-lock.json og ignorerer den alle andre steder end i rodprojektet. De applikationer, der installerer dit bibliotek, resolver selv dets afhængigheder inden for de intervaller, din package.json tillader.

Hvad gør integrity-feltet i package-lock.json?

Det indeholder en Subresource Integrity-hash, som regel sha512, af pakkens tarball. npm tjekker den downloadede pakke mod den, så en manipuleret tarball for en låst version ikke kan installeres. Den beskytter pakkerne i lockfilen, ikke noget, buildet henter uden for den.

Er en lockfile det samme som en SBOM?

Nej. En lockfile er et input: den plan, en pakkehåndtering følger for ét projekt. En SBOM er en fortegnelse over en release. SCA-værktøjer omsætter ofte en lockfile til en SBOM, og det virker, når buildet installerede præcis lockfilen og intet andet.