chore(deps): drop the 82 pnpm.overrides in frontend/ that never applied - #182
Conversation
pnpm prints this on every install:
WARN The field "pnpm.overrides" was found in frontend/package.json.
This will not take effect. You should configure "pnpm.overrides" at the
root of the workspace instead.
It is right. `frontend` is a workspace member with no lockfile of its own, and no
workflow installs it standalone — all 71 `pnpm install` invocations in this repo's
workflows run at the root. So those 82 entries have never resolved anything. They
read as security posture and are inert.
That is the reason to remove them rather than leave them: a block that looks like
82 CVE patches but applies none is worse than no block, because it answers the
question "is this handled?" wrongly.
Checked every entry before deleting, against the lockfile with real semver rather
than by eye:
- 39 distinct packages. For each selector, whether any INSTALLED version matches
it and fails to satisfy the target.
- Exactly one entry asks for more than the root overrides already provide —
`serialize-javascript@<7.0.5 -> >=7.0.5` against root's `>=7.0.3`. That intent is
preserved: root moves to `>=7.0.5`. The installed version is already 7.0.5, so
nothing resolves differently.
- Two entries would have changed something and are deliberately NOT carried over.
`@tootallnate/once@<3.0.1 -> >=3.0.1` (installed 2.0.1) is GHSA-vpq2-c234-7xj6,
severity LOW, and Dependabot does not raise it on this repo. `path-to-regexp ->
8.4.0` is an unconditional pin that would drag the installed 0.1.13 and 6.3.0
consumers across two majors — moving it to root would break builds, not fix them.
- Everything else is redundant with root coverage or targets a version not
installed here.
The lockfile does not move. A control regeneration on unmodified origin/main
produces the same `third-party-web 0.29.2 -> 0.30.0` drift from a floating range,
so that is pre-existing and is excluded here. The only lockfile line in this commit
is the serialize-javascript override, matching the root package.json change.
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Security Scan Results: PASSED
|
Verified: dropping these loses no protectionBefore merging I checked the obvious risk — that some of the 82 overrides were the only floor for a package, so removing them would silently drop a security bound. By package name, 22 of the 39 distinct packages in
That number is alarming and it is also misleading, which is the point of this comment. What the check actually has to beMy first pass compared each package's resolved versions against the highest The correct test is per selector: a resolved version is only a miss if it satisfies the vulnerable range and fails the target range. Run that way against the lockfile on And all three are benign. ConclusionZero packages are exposed by this removal. Which is what you would expect, because pnpm was already telling us so on every install: These 82 entries were inert. Nothing was being floored by them, so nothing can be lost by deleting them. The one entry that mattered is moved to the root in this PR. The 22 packages above are worth a separate look — not because this PR changes their exposure, but because the presence of a dead override made it look like they had a floor when they never did. |
PR Checks Summary
✅ All checks passed! Ready for review. |
1 participant
This deletes 82 lines that look like CVE patches. They are not — pnpm says so on
every install, and I verified it rather than taking pnpm's word for it.
frontendis a workspace member with no lockfile of its own, and no workflowinstalls it standalone — all 71
pnpm installinvocations in this repo'sworkflows run at the root. Those 82 entries have never resolved anything.
That is the reason to remove them, not a reason to hesitate. A block that
reads as 82 CVE patches and applies none answers "is this handled?" wrongly, which
is worse than not answering at all.
Every entry was checked before deletion
Against the lockfile, with real semver — for each selector, whether any installed
version matches it and fails to satisfy the target:
The one that asks for more is preserved. `serialize-javascript@<7.0.5 ->
The two that would change something are deliberately not carried over:
@tootallnate/once@<3.0.1 -> >=3.0.1, installed 2.0.1. That isGHSA-vpq2-c234-7xj6, severity low, and Dependabot does not raise it on this
repo. Worth its own decision, not a silent rider on a cleanup.
path-to-regexp -> 8.4.0, an unconditional pin. Installed are 0.1.13, 6.3.0and 8.4.2. Promoting this to root would drag the first two across two majors.
It would break builds, not fix them — which is probably why it never mattered
that this block was inert.
The lockfile does not move
The only lockfile line in this commit is the
serialize-javascriptoverride,matching the root
package.jsonchange.A regeneration on unmodified
origin/mainproduces the samethird-party-web 0.29.2 -> 0.30.0change from a floating range, so that drift ispre-existing and is excluded here rather than bundled in.
Verification
Run on this commit in an isolated checkout with no
../packagessibling — the wayCI runs, since no nchat workflow clones that sibling:
and the
pnpm.overridesWARN count drops from 1 to 0.