Skip to content

Fix BL-16525 vp test cannot resolve jsdom under vite-plus bundled runner #8049

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
hatton wants to merge 1 commit into
base: master
Choose a base branch
from
+1,474 −110
Draft

Fix BL-16525 vp test cannot resolve jsdom under vite-plus bundled runner #8049

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions ReadMe.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,8 @@ These are now being run using Vitest in the BloomBrowserUI folder (where all our

For now, all tests are being run using Node and JsDom. This approach has limitations; JsDom's emulation of the browser DOM is imperfect. In particular, you can't do much with a Canvas, and you can't get layout measurements. The file vitest.setup.ts contains various mocks to make jsdom work a little better. Eventually, we hope to be able to run a subset of tests using a real browser.

`pnpm test` is the canonical way to run the tests. Bare `vp test` also works, but only because `vite-plus` is a local devDependency: `vp` prefers a project-local vite-plus over its own bundled toolchain, and pnpm links our `jsdom` into the local install's vitest, whereas vp's bundled vitest cannot resolve `jsdom` at all (BL-16525). Note that `vp test` runs vite-plus's own vitest version, which may differ from the vitest pinned in package.json that `pnpm test` uses.

# Other Info

### Run more than one copy of Bloom
Expand Down
1 change: 1 addition & 0 deletions src/BloomBrowserUI/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -266,6 +266,7 @@
"vite": "7.1.5",
"vite-plugin-pug": "0.4.1",
"vite-plugin-static-copy": "3.1.3",
"vite-plus": "0.2.2",

@hatton hatton Jul 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Devin] Investigate: Adding vite-plus pulls in lightningcss as a transitive peer dependency of vite

Adding vite-plus@0.2.2 causes lightningcss@1.32.0 to be resolved as a peer dependency of vite@7.1.5. Previously, vite's resolution string was vite@7.1.5(@types/node@22.9.0)(less@3.13.1)(yaml@2.9.0) and it is now vite@7.1.5(@types/node@22.9.0)(less@3.13.1)(lightningcss@1.32.0)(yaml@2.9.0). While lightningcss is an optional peer dep of vite and this is expected, its presence can change CSS minification behavior in production builds (vite uses lightningcss for CSS minification when it's available). This is dev-only and unlikely to cause issues, but worth being aware of if CSS output changes are observed after this merge.

@hatton hatton Jul 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Claude Fable 5] Assessment: no behavior change expected. Vite only uses lightningcss when explicitly configured (css.transformer: 'lightningcss' or build.cssMinify: 'lightningcss') — mere presence in node_modules does not switch the CSS pipeline. This repo's vite.config.mts sets build.minify: false and never configures lightningcss, so it stays on the default (postcss/esbuild) path. The lockfile resolution-string change is real but inert.

"vitest": "4.0.8"
},
"lint-staged": {
Expand Down
Loading