Group
Dependencies2 min read

Reading a Lockfile: What Vibe Coders Miss

Your lockfile is a receipt for every line of code you ship. Here is how to actually read one, and what to look for before you deploy.

Most vibe coders never open their lockfile. It's a 40,000 line JSON file that appeared one day when they ran npm install, and it stays closed until Dependabot files a PR.

That's a mistake. Your lockfile is the exact, complete manifest of every line of third-party code you ship to production. It is worth ten minutes of your attention.

What a lockfile actually is

A package.json says "I want React 18-ish". A lockfile says "I want React 18.3.1, resolved from this exact URL, with this exact SHA-512 integrity hash, and here are its 412 transitive dependencies, pinned identically."

That last part is the interesting one. You don't have 47 dependencies. You have 47 direct dependencies and, usually, somewhere between 800 and 2,000 transitive ones.

What to look for

Duplicate versions of the same package

Open your package-lock.json and search for a common package name — say, lodash:

grep '"lodash":' package-lock.json | sort -u

If you see "lodash": "4.17.20" and "lodash": "4.17.21" in the same lockfile, you're shipping both. Your bundle is bigger, your attack surface is wider, and one of them almost certainly has a CVE.

Packages that look like other packages

Typosquatting is real. react-domm, lodashh, axioss — these exist, they get published to npm, and LLMs occasionally hallucinate them into your imports.

Postinstall scripts

Some packages run arbitrary code on install. Some of that code is legitimate (native builds). Some of it is not.

{
  "scripts": {
    "postinstall": "node ./scripts/download-binary.js"
  }
}

If a dependency you've never heard of has a postinstall script, that is a thing to look at before it runs on your CI machine with your deploy keys mounted.

The three-question audit

Before every production deploy, ask:

  1. Did any dependency version change since the last deploy? (git diff HEAD~1 package-lock.json)
  2. Do I know why?
  3. Did I run npm audit and read the output, or did I just run npm audit fix?

If the answer to any of those is no, you don't know what you're shipping. That's the whole point of the lockfile — to make sure you can know.

We run a full lockfile analysis as part of every Fortivibe audit, including CVE cross-reference and typosquat detection. It catches things nobody looks for otherwise.

Get an expert audit of your vibe coded app

Don't go live without letting an expert set of eyes review your code. Fortivibe runs 173 checks against your repo, reviewing things like security, stability, and user experience.

Get Your App Audited Now

Team Fortivibe Updated 9 days ago

Copy Link