Getting SolidJS to work with a vitest workspace structure

[MrJohz]

Hi, I've consistently had issues with getting the solidjs vite plugin to work properly with vitest's workspace structure. I've already raised an issue in that repository (solidjs/vite-plugin-solid#102), but I'm trying to debug the problem further and I'm not sure if it's a problem with the plugin, or a problem somewhere else with Vitest.

The minimum reproduction is here: https://stackblitz.com/edit/solidjs-templates-zxnf4p?file=README.md

The problem is roughly this:

• For a single project (e.g. npx -w frontend vitest), all the SolidJS-related imports get resolved to their development versions (i.e. the builds with extra debugging information). This is partly configured by the SolidJS Vite plugin, which also handles deduping those files so there aren't multiple versions of SolidJS running at once. This is the goal.
• For a whole workspace (e.g. npx vitest), some of the imports resolve to their development versions, and others to their production versions. This mismatch causes errors as files try to access debug information that isn't there.
• For a whole workspace with the SolidJS plugin removed, Vitest correctly resolves the correct imports, but doesn't dedupe the files correctly. (This isn't visible in the reproduction because there's only one test, but I believe if you add different tests, potentially in different files, warnings should start appearing.)

Some notes I've made while trying to debug this:

• The plugin makes changes to the Vite config, including the test config, but the resolved config is identical for single-project and workspace runs.
• Removing the plugin ensures that everything gets resolved correctly, except for the duplicate imports.
• The plugin works correctly for Vite itself in all situations I've tried it in. It's only with Vitest (and only with Vitest workspaces) that things start breaking.

My questions:

• Where can I see/debug how an import is being resolved by Vitest?
• Are there any obvious culprits that I should look at first?
• Does this feel more like a bug in Vitest, or a bug in the plugin?

Thanks for any help/advice that you can offer. As you can see from the original issue, I've been running into this same issue for over a year now, and it would be really good to get it fixed soon! I'm happy to implement the necessary changes, but I'm unsure where to start right now.

[hi-ogawa]

• Where can I see/debug how an import is being resolved by Vitest?

The first thing I tried is to run Vitest with VITE_NODE_DEBUG_DUMP=1. This will dump Vitest/Vite's transform, so you can see how import is rewritten. For example, I can see solid-js/store became .../node_modules/solid-js/store/dist/dev.js https://stackblitz.com/edit/solidjs-templates-em2dzk?file=debug-vite-node-frontend%2F_home_projects_solidjs-templates-zxnf4p_frontend_test_spec_ts--1534932233.js

Looking at this, the transform seems same, so the next thing I suspected is NodeJS import condition and indeed it looks like there's a difference if you print process.execArgv https://stackblitz.com/edit/solidjs-templates-em2dzk?file=frontend%2Ftest.spec.ts

// npm run test-fe-only
[
  '--conditions',
  'development',
  '--conditions',
  'solid',
  '--conditions',
  'browser',
  '--conditions',
  'node'
]

// npm run test-all
[process.execArgv] [ '--conditions', 'development', '--conditions', 'node' ]

Then I remembered now this is a known issue and custom resolve condition like https://github.com/solidjs/vite-plugin-solid/blob/873f4cec4db1dcffac9d909191cf828a9902a418/src/index.ts#L239-L243 is not supported for Vitest workspace.

• Vitest doesn't honor resolve conditions for nested modules in workspace. #5301

There might be a few workaround for this. Like Marko's case, you might try deps.optimizer.web.enabled (and/or server.deps.inline). Or you can give up running unit test on NodeJs/jsdom and use browser mode instead.

[MrJohz]

Thank you so much! Particularly, thanks for explaining how you figured that out, that was useful to be able to follow.

I've got my test suite working — I think it's not as efficient as it could be, but working slowly is better than failing!

For people who stumble on this in the future (probably me in a year's time again 😅), I needed to use server.deps.inline in my frontend's vite.config.ts, like this:

export default defineProject({
  plugins: [solidPlugin(), solidSvgPlugin({ defaultAsComponent: false })],
  server: { /* ... */ },
  build: { /* ... */ },
  test: {
    // ...
    server: {
      deps: { inline: true },
    },
  },
});

I think it should be possible to replace inline: true with something more specific (e.g. inline: [/solid-js/], but trying that naively didn't work, and I was happy enough with inline: true for my use case.