You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vitest has a workspaces feature, where vitest can be made aware of different sub-projects, and run the tests for each of these workspaces (based on their individual configuration) together.
However, when using Vitest workspaces andvite-plugin-solid, the solid-js resolution system fails to work properly, and functions like createStore() throw errors.
This is because in dev-mode, the createStore tries to access the DEV object exported by solid-js. This DEV object is only available if solid-js is running in dev mode (in production, a different file is used which sets DEV to undefined).
However, for some reason, when Vite/NodeJS/Vitest/? tries to resolve the import solid-js from node_modules/solid-js/store/dist/dev.js, it instead imports the production version of solid-js, which obviously doesn't have the correct exported DEV object, and so an error is thrown.
I'm creating this issue here, because the error only occurs if vite-plugin-solid is installed, but I'm not entirely sure what this plugin is doing that makes things behave weirdly here. There isn't any JSX to process, so I would have through the plugin is essentially a no-op.
Thanks for any help!
The text was updated successfully, but these errors were encountered:
I have reported the same issue: #104. But in my case the tests pass on GitHub Actions and for other developers who run Node.js 16. Your example runs v16.20.0 but still fails.
I have been running into really odd behavior with vitest and the solid vite plugin and am curious if you all think this is related? See details below, but basically whenever I have the plugin enabled, all my unit tests (whether using solid or not) run twice! It is super odd and frustrating that I cannot get to the bottom of it.
Hi, I ran into this same problem again, and ended up asking about it on the Vitest project: vitest-dev/vitest#6537 It looks like there is a known bug in Vitest affecting this (vitest-dev/vitest#5301). This plugin may be able to work around this by changing configuration settings.
I was able to add test.server.deps.inline: true to my vite configuration, and that worked fine, but there are some other suggestions in the linked discussion.
Description
Vitest has a workspaces feature, where vitest can be made aware of different sub-projects, and run the tests for each of these workspaces (based on their individual configuration) together.
However, when using Vitest workspaces and
vite-plugin-solid
, thesolid-js
resolution system fails to work properly, and functions likecreateStore()
throw errors.Reproduction
https://stackblitz.com/edit/solidjs-templates-4usktg?file=README.md&view=editor
The problem can be reproduced by running
npm run test-all
in the console. This runs a test that just callscreateStore
.Running
npm run test-fe-only
runs vitest in thefrontend/
package, which bypasses Vitest's workspaces system, everything works again.Running
npm run test-all-no-plugin
runs vitest the same as intest-all
, but with thevite-plugin-solid
plugin disabled. Again, this works as expected.Error/Investigation
The error returned is:
This is because in dev-mode, the
createStore
tries to access theDEV
object exported bysolid-js
. ThisDEV
object is only available ifsolid-js
is running in dev mode (in production, a different file is used which setsDEV
to undefined).However, for some reason, when Vite/NodeJS/Vitest/? tries to resolve the import
solid-js
fromnode_modules/solid-js/store/dist/dev.js
, it instead imports the production version ofsolid-js
, which obviously doesn't have the correct exportedDEV
object, and so an error is thrown.I'm creating this issue here, because the error only occurs if
vite-plugin-solid
is installed, but I'm not entirely sure what this plugin is doing that makes things behave weirdly here. There isn't any JSX to process, so I would have through the plugin is essentially a no-op.Thanks for any help!
The text was updated successfully, but these errors were encountered: