# Lockfile contains every declared dependency

- **Pattern:** `ab-000024` (`ai-slop-hallucinations.module-references.lockfile-package-consistency`)
- **Severity:** high
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000024
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000024)

## Why it matters

A stale lockfile is a reference-integrity failure at the supply-chain layer (SLSA 1.0 L1): the declared dependency exists in `package.json` but has no pinned version in the lockfile, so every fresh install can resolve a different version — including one with a known CVE that your pinned version avoided. Beyond security, the presence of two competing lockfiles (`package-lock.json` + `yarn.lock`) is a distinct AI confusion signal that indicates the model switched package managers mid-session, leaving the project with contradictory resolution graphs that CI will handle unpredictably.

## Severity rationale

High because unpinned transitive dependencies silently admit supply-chain version drift that can introduce security regressions across deploys.

## Remediation

Delete stale or conflicting lockfiles and regenerate from the correct package manager. If multiple lockfiles coexist, pick one and remove the others before running install.

```bash
# npm
rm -rf node_modules package-lock.json && npm install

# yarn
rm -rf node_modules yarn.lock && yarn install

# pnpm
rm -rf node_modules pnpm-lock.yaml && pnpm install

# bun
rm -rf node_modules bun.lockb && bun install
```

Commit the regenerated lockfile. If `package-lock.json` and `yarn.lock` both exist, the project cannot have a deterministic install until one is deleted.

## Detection

- **ID:** `lockfile-package-consistency`
- **Severity:** `high`
- **What to look for:** Read `package.json` and extract every package name from `dependencies`, `devDependencies`, `peerDependencies`, and `optionalDependencies`. Then read the lockfile (one of `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `bun.lockb`). For each package in `package.json`, verify the lockfile contains an entry for it. Skip workspace-only packages declared with `workspace:*` protocol. Count all declared packages, total in lockfile, total missing from lockfile.
- **Pass criteria:** Every package in `package.json` (excluding workspace-protocol entries) has a corresponding entry in the lockfile. Report: "X declared packages, Y in lockfile, 0 missing."
- **Fail criteria:** At least 1 declared package is absent from the lockfile, indicating the lockfile is stale or was never run after a `package.json` edit.
- **Do NOT pass when:** Multiple lockfile types exist simultaneously (e.g., both `package-lock.json` and `yarn.lock`) — this is a different AI confusion signal and should fail with detail noting the lockfile conflict.
- **Skip (N/A) when:** No lockfile exists at the project root AND `package.json` declares 0 dependencies.
- **Report even on pass:** Report the lockfile type and counts. Example: "Lockfile: package-lock.json. 87 declared packages, 87 in lockfile (100%)."
- **Detail on fail:** `"3 declared packages missing from package-lock.json: 'date-fns', 'zod', 'react-hook-form'. Run 'npm install' to regenerate the lockfile."` or `"Multiple lockfiles found: package-lock.json AND yarn.lock. Pick one package manager and delete the other."`
- **Remediation:** A stale lockfile means the AI added a dependency to `package.json` but never ran the install command. Fix it:

  ```bash
  # For npm projects
  rm -rf node_modules
  npm install

  # For yarn projects
  yarn install

  # For pnpm projects
  pnpm install

  # For bun projects
  bun install
  ```

  Then commit the regenerated lockfile. If multiple lockfiles exist, decide which package manager you're using and delete the others.

## External references

- slsa L1

Taxons: supply-chain, reference-integrity

HTML version: https://auditbuffet.com/patterns/ab-000024