@vitest/web-worker error when using jsDOM environment

[darwin-baxter]

Describe the bug

I am trying to run test cases in my application which needs both web-workers and DOM for successfully running the test case. As we know jsDOM environment doesn't have the support for web-workers so I figured I would use the @vitest/web-workers for adding the support for the same.

Now, in theory I don't see any problem with this but when I am trying to run the test suites, I am getting a dynamic error like this:

Here as you can see, the error is originating from Object.worker.send in workerpool->worker.js and is looking for postMessage().
Now, logically it should go ahead an hit the postMessage() in the vitest/web-workers scope, but somehow we can see that it goes to the jsDOM's scope of window.postMessage().
If the scope is dedicated globally in the context of web-workers, it might solve the issue.

Reproduction

Here is the link to the minimal reproduction repo on gitHub: repository

System Info

System:
    OS: Windows 11 10.0.22621
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 3.79 GB / 15.73 GB
  Binaries:
    Node: 20.17.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (128.0.2739.79)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    @vitejs/plugin-react: ^4.3.4 => 4.3.4 
    @vitest/web-worker: ^2.1.8 => 2.1.8 
    vite: ^6.0.1 => 6.0.2 
    vitest: ^2.1.8 => 2.1.8

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

This is because workerpool package is cjs and they are not transformed by Vitest. server.deps.inline alone doesn't work either since that doesn't reach transitive require of workerpool/src/worker.js. https://github.com/josdejong/workerpool/blob/6bf949e2db2e909522d50c7236390c46b87ddf2f/src/index.js#L38

The workaround I found is to set server.deps.inline: ["workerpool"] and also import workerpool/src/worker.js directly like this:
https://stackblitz.com/edit/github-hozk3a?file=src%2Fworker%2Fapi_worker.ts

import workerpool from 'workerpool/src/worker';

const getSquare = (x: number) => {
  return x * x;
};

workerpool.add({
  getSquare,
});

[darwin-baxter]

Hello Hiroshi, thanks for the response, I tried out the changes you mentioned in my vs code env but it doesn't seem to work for me, it is now throwing a new error, I am attaching the same for your reference, it would be great if you can look into this and try replicating in a vs code environment.

Also, you mentioned that the workerpool package is in cjs and that is not being transformed by Vitest. Builiding on that context do you think that getting an esm build of the workerpool package will fix the issue all-together, if it is at all possible to verify it once, I would really appreciate the help.
Thanks

[hi-ogawa]

I tried out the changes you mentioned in my vs code env but it doesn't seem to work for me, it is now throwing a new error

I'm not sure what you mean. Downloading and locally running this #7023 (comment) is working for me. If you have a different error, can you provide a reproduction for that?

[darwin-baxter]

Hello Hiroshi, I am not being able to create a new reproduction of the error, the screen snip I attached above is what I am facing in the current set up itself.

Anyways, lets keep that aside, I wanted to check with you that if we get the esm module support from the workerpool library will it solve the issue without having to do these work arounds. Let me know what you think about this.
Thanks for your time, I appreciate it,

[hi-ogawa]

I wanted to check with you that if we get the esm module support from the workerpool library will it solve the issue without having to do these work arounds.

Yes. If workerpool is implemented/published in a way that it avoids the use of require internally, then I'd expect server.deps.inline: ["workerpool"] should be enough to make it work.