chore(security): bump @humanfs/node to ^0.16.8 (GHSA-p498-v437-472g, alert #74)

[benfrank241]

Daily security sweep — npm / root package-lock.json.

Dependabot's own PRs don't get CI secrets on this repo, so this recreates the fix on a human-authored branch that does.

Closes

Alert	Advisory	Sev	Package	Scope	Fix
#74	GHSA-p498-v437-472g	medium	@humanfs/node	dev	0.16.6 → 0.16.8

@humanfs/node's copyAll() doesn't treat symlinks as a distinct case — it hands every non-directory entry to fs.promises.copyFile(), which dereferences symlinks. A symlink inside an attacker-controlled source tree therefore copies the contents of any file readable by the process, from outside the tree being copied.

Change

Not a direct dependency. The sole declaring parent is eslint@9.39.4, which requests @humanfs/node@^0.16.6 — a range that already accepts the patched 0.16.8. Since no parent disagrees, a plain global override is correct; no scoping needed.

"overrides": { "@humanfs/node": "^0.16.8" }

Caret, not >=, so npm can't jump the major. Relocked with npm install --package-lock-only; resolved version re-read from the lockfile to confirm it actually moved to 0.16.8.

Lockfile churn is confined to the @humanfs family and is all dev-scope:

• @humanfs/node 0.16.6 → 0.16.8
• @humanfs/core 0.19.1 → 0.19.2 (required by the above)
• @humanfs/types 0.15.0 added (new dependency of both)
• nested @humanfs/node/node_modules/@humanwhocodes/retry 0.3.1 removed — 0.16.8 widened its request to ^0.4.0, which dedupes to the existing top-level 0.4.3

No other package keys changed.

Verification

This repo's next build gate is already red on main from pre-existing ESLint errors (see #17), so a passing build isn't available as a signal. Both halves of the standard evidence were gathered instead:

1. Differential — npm ci && npm run build && npm run lint run on this branch and on a pristine origin/main worktree. Both fail identically: CI=0, BUILD=1, LINT=1 on each side, and the normalized signature set (6 files + 6 diagnostics — 2 no-explicit-any errors, 4 no-unused-vars warnings) is identical. No new failure introduced.
2. True green — both sides rebuilt with only the unrelated ESLint gate bypassed via a temporary, uncommitted eslint.ignoreDuringBuilds edit. Both exit 0. The edit was reverted; only package.json and package-lock.json are in this diff.
3. Behavioural evidence for the bumped package specifically — @humanfs/node is ESLint's filesystem abstraction, used to read config and traverse files. ESLint ran to completion under 0.16.8 and emitted a byte-identical diagnostic set to 0.16.6. That the file-traversal layer produces identical results across the bump is direct evidence it's behaviour-neutral here.

npm audit after the change reports only the one low-severity finding below, which is already covered.

Not included

• Alert #73 / GHSA-w9m9-85wc-3x92 (postcss-selector-parser, low, dev) is already fixed by chore(security): bump postcss-selector-parser >=6.1.3 (GHSA-w9m9-85wc-3x92, alert #73) #18, still open. Deliberately not duplicated here.

Important

#18 and this PR touch the same package.json overrides block and the same lockfile. They are intentionally not stacked — both branch from main so each gets CI (a PR based on a non-default branch wouldn't match this repo's workflow triggers). Whichever merges second needs a rebase and a re-run of npm install --package-lock-only.

Not merging — maintainer's call.