Upgrade vitest v2 → v3 and regenerate the lockfile#17
Merged
Conversation
vitest 2.1.9 has a critical advisory (arbitrary file read/exec via the UI server, fixed in 3.2.6) and pulled an ancient jsdom@16 as a kept peerOptional, which in turn dragged in the only vulnerable copies of form-data (critical) and lodash (high, no npm fix on the 4.x line) left in the tree. Our tests use the "node" environment, so jsdom was never actually used. - Bump vitest to ^3.2.7 (clears the vitest critical; pulls modern vite 7.x, so the old vite/rollup/esbuild dev advisories drop out). - Regenerate package-lock.json from scratch. Most of the remaining alerts were lockfile *staleness*, not version-range blockers: the direct deps' semver ranges already permitted patched transitive versions, so a fresh resolve drops jsdom entirely and refreshes braces, cross-spawn, semver, ws, picomatch, minimatch, tar-fs, flatted, etc. to their fixed versions. (This is why overrides were the wrong tool here.) The regen also floats @xenova/transformers 2.2.0 -> 2.17.2 within its existing ^2.2.0 range, which clears sharp. npm audit: 37 -> 7. The remaining 7 are the @xenova/transformers cluster (protobufjs / onnx-proto / onnxruntime-web, addressed in the next PR) plus three build-tool moderates (esbuild / tsup / tsx). Verified: npm run build, npm test (23 pass), npm run lint, npm run format:check all green; @xenova/transformers 2.17.2 and the embedder surface still load. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Root cause #3 of 3
vitest@2.1.9has a critical advisory (arbitrary file read/exec via the Vitest UI server, fixed in 3.2.6) and pulled an ancientjsdom@16as a keptpeerOptional. That jsdom was the only remaining source of theform-datacritical and thelodashhigh (which has no npm fix on the 4.x line). Our tests run in thenodeenvironment, so jsdom was never actually used.Changes
vitest→^3.2.7— clears the vitest critical and pulls modernvite@7, so the stalevite/rollup/esbuilddev advisories drop out. (Chose v3 over v4 because v4 requires bumping@types/nodeoff 18; v3 keeps the PR minimal.)package-lock.json. This is the key insight of the whole effort: most of the alert backlog was lockfile staleness, not version-range blockers. The direct deps' semver ranges already permitted patched transitive versions, so a fresh resolve dropsjsdomentirely and refreshesbraces,cross-spawn,semver,ws,picomatch,minimatch,tar-fs,flatted, etc. to their fixed versions — no overrides needed. The regen also floats@xenova/transformers2.2.0 → 2.17.2 within its existing^2.2.0range, which clearssharp.Impact
npm audit: 37 → 7. The remaining 7 are the@xenova/transformerscluster (protobufjs/onnx-proto/onnxruntime-web— root cause #2, next) plus three build-tool moderates (esbuild/tsup/tsx).Verification
npm run build,npm test(23 pass),npm run lint,npm run format:check— all green.@xenova/transformers2.17.2 and theembeddersurface still load after the within-range float.🤖 Generated with Claude Code