fix(deps): regenerate lockfile so the CVE overrides actually apply - #174
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
ntask main's Dependency Audit (OSV) went red on 2026-09-13 against commit 4fa5078 — the same commit that passed on 09-04 and 09-06. The code did not change; the advisory database did. hono@<4.13.5 -> ^4.13.5 js-yaml@<4.3.2 -> ^4.3.2 vitest@<4.1.11 -> ^4.1.11 but pnpm-lock.yaml was never regenerated, so it still pinned hono@4.13.2, js-yaml@4.3.1 and vitest@3.2.6. OSV scans the lockfile, not the override block, so those overrides were inert and the audit stayed red. This is the missing half of #172. After a fresh install the lockfile resolves hono@4.13.7, js-yaml@4.3.2 and vitest@4.1.11. The vitest override crosses a major, so the three packages that declare it (web, apps/cli, apps/mcp) move from ^3.2.6 to ^4.1.11 to match rather than silently diverge from the resolved tree. Vitest 4 also removed the "poolOptions" nesting — those per-pool settings are top-level options now — so web/vitest.config.ts is migrated, which clears the DEPRECATED warning the first v4 run emitted. Behaviour is unchanged: one bounded fork, same 2GB execArgv ceiling. Verified locally on 4.1.11: web 28 files / 461 tests pass apps/cli 4 files / 16 tests pass apps/mcp 1 file / 2 tests pass sharded coverage gate: lines 54.05% >= 54%, functions 46.65% >= 40%, branches 44.61% >= 40% No gate weakened: no IgnoredVulns entry added, no threshold lowered, no test skipped.
acamarata
force-pushed
the
fix/osv-advisories-2026-09-13
branch
from
September 13, 2026 08:05
9e73688 to
f5fb50d
Compare
acamarata
changed the title
The previous lockfile was generated against a local packages/ clone that was 12 days stale (3e6d061, 2026-08-31) while origin/main is bf33eda3 (2026-09-12). CI clones packages fresh on every run, so its package.json set did not match what the lockfile recorded and both installs died: ERR_PNPM_OUTDATED_LOCKFILE Cannot install with frozen-lockfile because pnpm-lock.yaml is not up to date with <ROOT>/packages/@nself-web/csp/package.json Regenerated against packages@bf33eda3. Verified pnpm install --frozen-lockfile now exits 0, the same invocation both CI jobs use, and web still passes 28 files / 461 tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Main is red, and the overrides that should have prevented it are inert
Dependency Audit (OSV)on main went failure 2026-09-13 04:32 against commit4fa5078b— the same commit that passed on 09-04 and 09-06. The code did notchange; the advisory database did.
The interesting part is that main already had the correct overrides, added by
#172:
But
pnpm-lock.yamlwas never regenerated after they were written, so it stillpinned:
OSV scans the lockfile, not the override block. So those overrides have been
doing nothing since #172 merged, and the audit reported exactly the versions they
were supposed to have replaced. This PR is the missing half of #172.
After a fresh install the lockfile resolves
hono@4.13.7,js-yaml@4.3.2,vitest@4.1.11.This is worth remembering as a class of bug: an override block that reads correctly
in review while the artifact the scanner actually reads is untouched. A green
override list is not evidence.
The vitest major
vitest@<4.1.11 -> ^4.1.11crosses a major. GHSA-82fw-gwwq-j7x9 (Path Traversal /Arbitrary File Read via @vitest/mocker Redirect Mock) lists
fixed: 4.1.11with no3.x backport, so #172's override was already committing to v4 — the lockfile just
never caught up.
The three packages that declare vitest (
web,apps/cli,apps/mcp) move from^3.2.6to^4.1.11so the declarations match the resolved tree instead of silentlydiverging from it.
Vitest 4 removed the
poolOptionsnesting; those per-pool settings are top-leveloptions now. The first v4 run printed:
web/vitest.config.tsis migrated accordingly. Behaviour is unchanged — one boundedfork, same
--max-old-space-size=2048ceiling, same reason (the ~5.6GB render-loopleak documented in that file).
Verification — all three suites on 4.1.11
webapps/cliapps/mcpThe sharded run matters:
pnpm test:coveragedrives two fresh vitest processes viavitest.shard.config.ts, which inherits the base config changed here.No gate weakened
No
IgnoredVulnsentry added, no coverage threshold lowered, no test skipped, nocontinue-on-error.