Update dependencies with evidence

A dependency update is code written by someone else landing in your package graph. Treat it like any other code change: review, test, record evidence.

I update in small groups instead of one giant npm update PR that touches forty packages.

Inspect before and after

Pick one runtime dependency, for example unicode-properties:

npm ls unicode-properties
npm update unicode-properties
git diff package-lock.json

Read the diff. New packages under that subtree? Changed hasInstallScript flags? Those deserve a manual look at the upstream release notes.

npm view unicode-properties@latest version repository

Check the maintainer and changelog on GitHub before you merge.

Run the full gate

After the lockfile changes:

npm ci
npm test
npm run build
npm pack --dry-run
node scripts/consumer-smoke.mjs

All green? Write why the update is safe in the PR description: “Patch release, no API changes, consumer smoke passed.”

If something fails, bisect. Revert the lockfile hunk for that dependency and try the next version down.

Watch install scripts

Packages with "hasInstallScript": true can run code on every install. I read their postinstall script before approving the bump. A compromised or careless script in your tree becomes your incident.

Automated renovate bots are fine as openers. A human still owns the merge button and the explanation.

Never merge “because semver said patch” without running your consumer fixture. The number is a hint, not proof.

When a bot opens five dependency PRs in one day, batch them if they touch the same subtree. One lockfile diff with one test run beats five separate merges that each hide a small risk.

Record the upstream advisory link in the PR when the update fixes a CVE. That paper trail helps the next maintainer understand why a pin exists.