Part 8 · 1 chapters · ~10 min

The npm Supply Chain

The frontend's exposure to other people's code: the real size of the dependency tree, lockfiles and npm ci, install scripts disabled by default, typosquats and account takeovers, provenance attestations and signature checks, and a habit of small scheduled updates triaged by reachability.

Other people's code, on purpose

code

# .npmrc: no install scripts by default
ignore-scripts=true

# pnpm: allow only the packages that genuinely need to build (package.json)
"pnpm": { "onlyBuiltDependencies": ["esbuild", "sharp"] }

# CI
npm ci                         # exact lockfile, integrity checked
npm audit signatures           # registry signatures and provenance attestations
npm ls --all | wc -l           # how big is the tree, really?

# renovate.json: grouped, scheduled, with a cool-off for brand-new versions
{ "extends": ["config:recommended"], "schedule": ["before 9am on monday"],
  "minimumReleaseAge": "3 days", "packageRules": [{ "matchUpdateTypes": ["minor", "patch"], "groupName": "non-major" }] }

before adding a dependency, ask	why
can we write it in under a hundred lines?	a small function you own beats a package you must watch
how many transitive packages does it add?	each is another maintainer and another risk
is it maintained, with more than one maintainer and provenance?	bus factor and takeover risk
does it run install scripts?	code execution at install time
what does it add to the bundle users download?	performance on low-end phones

THE NPM SUPPLY CHAIN

a frontend app is mostly other people's code: lockfiles, install scripts, typosquats, provenance and update hygiene

swipe the figure sideways, or tap expand for full screen

1/6

the size

The size of it: a fresh framework app commonly pulls in hundreds of packages before you add your own. Run npm ls --all or look at the lockfile to see the real tree. Every package is code from a maintainer you have never met, with the ability to run during install.