chore(deps): clear 56 of the 62 open transitive advisories in the root lockfile - #56
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
radroid
commented
Aug 8, 2026
Correcting the counts in the description. I wrote them before #52 landed and they were off by one in two places. Measured against the live alert data rather than my earlier arithmetic:
So the split is 4 knowingly deferred and 2 that look stale, not the "5 genuinely open" the description says. The title is updated; the reasoning in the table is unchanged. |
radroid
commented
Aug 8, 2026
Correction to the description: the last two alerts are not stale. I wrote that What they actually are, and why each is still deferred rather than fixed:
So the real remaining count is 6, split 4 deferred with reasons ( |
…eep reopened Fallout from #56, caught by re-checking the alert list after it merged rather than assuming the count only goes down. Before the sweep the tree had one nanoid@3.3.12, and GHSA #115/#116 against it sat auto-dismissed by GitHub's auto-triage rule — it was scoped as a development dependency. astro 7.2.0 restructured its tree, adding an already-fixed nanoid@3.3.17 alongside the old copy and flipping that copy's scope to runtime, which took it out from under the rule and reopened both alerts. The sweep did not introduce a vulnerability — 3.3.12 was there before and was always affected — but it turned a suppressed finding into a live one. One override, "nanoid@3": ^3.3.17, dedupes onto the version already in the tree. Both advisories want <= 3.3.17, so this clears both. Ledger figures refreshed in the same commit per SEAMS.md's self-reference rule.
…eep reopened Fallout from #56, caught by re-checking the alert list after it merged rather than assuming the count only goes down. Before the sweep the tree had one nanoid@3.3.12, and GHSA #115/#116 against it sat auto-dismissed by GitHub's auto-triage rule — it was scoped as a development dependency. astro 7.2.0 restructured its tree, adding an already-fixed nanoid@3.3.17 alongside the old copy and flipping that copy's scope to runtime, which took it out from under the rule and reopened both alerts. The sweep did not introduce a vulnerability — 3.3.12 was there before and was always affected — but it turned a suppressed finding into a live one. One override, "nanoid@3": ^3.3.17, dedupes onto the version already in the tree. Both advisories want <= 3.3.17, so this clears both. Ledger figures refreshed in the same commit per SEAMS.md's self-reference rule.
…eep reopened Fallout from #56, caught by re-checking the alert list after it merged rather than assuming the count only goes down. Before the sweep the tree had one nanoid@3.3.12, and GHSA #115/#116 against it sat auto-dismissed by GitHub's auto-triage rule — it was scoped as a development dependency. astro 7.2.0 restructured its tree, adding an already-fixed nanoid@3.3.17 alongside the old copy and flipping that copy's scope to runtime, which took it out from under the rule and reopened both alerts. The sweep did not introduce a vulnerability — 3.3.12 was there before and was always affected — but it turned a suppressed finding into a live one. One override, "nanoid@3": ^3.3.17, dedupes onto the version already in the tree. Both advisories want <= 3.3.17, so this clears both. Ledger figures refreshed in the same commit per SEAMS.md's self-reference rule.
…eep reopened Fallout from #56, caught by re-checking the alert list after it merged rather than assuming the count only goes down. Before the sweep the tree had one nanoid@3.3.12, and GHSA #115/#116 against it sat auto-dismissed by GitHub's auto-triage rule — it was scoped as a development dependency. astro 7.2.0 restructured its tree, adding an already-fixed nanoid@3.3.17 alongside the old copy and flipping that copy's scope to runtime, which took it out from under the rule and reopened both alerts. The sweep did not introduce a vulnerability — 3.3.12 was there before and was always affected — but it turned a suppressed finding into a live one. One override, "nanoid@3": ^3.3.17, dedupes onto the version already in the tree. Both advisories want <= 3.3.17, so this clears both. Ledger figures refreshed in the same commit per SEAMS.md's self-reference rule.
…eep reopened Fallout from #56, caught by re-checking the alert list after it merged rather than assuming the count only goes down. Before the sweep the tree had one nanoid@3.3.12, and GHSA #115/#116 against it sat auto-dismissed by GitHub's auto-triage rule — it was scoped as a development dependency. astro 7.2.0 restructured its tree, adding an already-fixed nanoid@3.3.17 alongside the old copy and flipping that copy's scope to runtime, which took it out from under the rule and reopened both alerts. The sweep did not introduce a vulnerability — 3.3.12 was there before and was always affected — but it turned a suppressed finding into a live one. One override, "nanoid@3": ^3.3.17, dedupes onto the version already in the tree. Both advisories want <= 3.3.17, so this clears both. Ledger figures refreshed in the same commit per SEAMS.md's self-reference rule.
Follow-up to #52. Dependabot opened no PRs for any of these — it generally cannot auto-fix transitive pnpm dependencies — so they had been accumulating untouched.
What moved
Two levers, deliberately in that order, because the cheaper one covers more than it looks.
1. Re-resolution, no config change at all. Several of these were already satisfiable by the ranges their parents declare; the lockfile was just holding a stale resolution.
pnpm update -r --lockfile-onlycleared astro (7.0.3 → 7.2.0), postcss (8.5.15 → 8.5.26), svgo (4.0.1 → 4.0.2), js-yaml (4.2.0 → 4.3.1) and undici@7 (7.27.1 → 7.29.0).pnpm updatewanted to rewriteapps/marketing/package.json's specifier to^7.2.0as it went; I reverted that and re-resolved, and 7.2.0 holds under the original^7.0.3. Nopackage.jsonin the repo is touched by this PR.2. Twelve major-scoped
overrides:for the rest, appended to the block upstream already maintains inpnpm-workspace.yaml: brace-expansion (all three major lines), builder-util-runtime, fast-uri, form-data, hono, ip-address, path-to-regexp, shell-quote, tar, undici@6. Every key is pinned to a major —"tar@7": ^7.5.21, nottar: ^7.5.21— so no entry can silently cross a major in a package nothing here imports directly.Net effect on the lockfile is a shrink of 413 lines: astro 7.2.0 sheds its old remark/rehype/hast pipeline.
What I deliberately did not fix
image-size1.2.1<= 2.0.2with no fix published. Nothing to bump to.sharp0.34.5allowBuildsentry. In0.xa minor bump is a breaking change; an override here risks the desktop build for one high advisory. Wants its own PR.uuid7.0.3uuid@7, not forcing 11 underneath it.Two more alerts —
@hono/node-serverand@vitest/browser(critical) — name packages that are not in the lockfile at all. They look stale and should auto-close once GitHub rescans the default branch after this lands. Worth confirming rather than assuming.That leaves 5 genuinely open, from 64.
Ledger
pnpm-workspace.yamlbecomes row 37.pnpm-lock.yamlgoes to risk 67136, five times the next row — and I added a note under the header saying not to read that number at face value: the lockfile is regenerated at every sync rather than merged, so the cost is onepnpm install, not a thousand conflict decisions. The 18-lineoverrides:block is what actually has to survive a sync, and it is the row to defend.Verification is CI — typecheck, lint and the full suite. I did not install
node_moduleslocally to run them; this machine is disk-constrained and the resolve was lockfile-only.