nanoid advisory 1139427

A transitive dependency three levels down turned every PR in the repo red, one hour after main was green.

The timeline that identifies it as environmental

15:36  main CI                 GREEN     c8c6098b5
       └─ advisory 1139427 + the 3.3.18 fix publish in this window
16:38  PR #3480 CI              RED       23c6890c0

lockfiles on #3480 vs main: BYTE-IDENTICAL
nanoid mentions in #3480's diff: 0

This is the signature of a newly-published advisory rather than a branch defect: nothing in the PR touched dependencies, and the same lockfile was green an hour earlier. Every open PR and main itself would fail their next run.

Where nanoid actually comes from

src/hooks orchestkit-demos generic-client

Nothing declares nanoid directly. If the fix had required a new vite major, this would have been a migration instead of three lockfile lines.

Why the bump was cheap

$ npm audit --json
  nanoid: severity=high  range=<3.3.18
  fixAvailable: True
  effects: []                    <- nothing depends on the vulnerable range
  nodes: ['node_modules/nanoid'] <- a single node

effects: [] is the load-bearing field. It means no direct dependency pins the vulnerable range, so npm can bump the nested copy without touching a manifest. 3.3.18 is a drop-in patch.

The whole diff

-  "version": "3.3.17",
+  "version": "3.3.18",      x3 lockfiles, and nothing else

Verified by enumerating every changed package name in the diff, not by eyeballing it: the only value that appears on a + line is 3.3.18.

Verification

checkbeforeafter
test-npm-audit.sh3/6 passed6/6, 0 findings
vitest (pulls nanoid)1744 tests green
npm run typecheckclean

Running vitest was the point, not a formality: nanoid is pulled by the test runner itself, so a bad bump surfaces as runner breakage rather than a compile error. A typecheck alone would not have caught it.