Prefer worker condition for web-workers

[stevemk14ebr]

trafficstars

Clear and concise description of the problem

Please refer to the webpack issue here: https://github.com/webpack/webpack/issues/14681. In short, when resolving a module that is used within a webworker, try fields worker or webworker before browser. This helps libraries seperate browser DOM api code from code that also runs in the browser, but does not have DOM api access. To do this now, users must configure like so:

  resolve: {
	  conditions: ['worker', 'webworker']
  }

I suggest this be done automatically.

For libraries such as this that need to choose a different conditional export based upon usage. https://github.com/wooorm/parse-entities/issues/19

Suggested solution

First try worker or webworker fields if the module is imported from a webworker.

Alternative

No response

Additional context

No response

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

This makes sense to me since we already have node and browser platform conditions, but maybe we should check worker only (without webworker) to keep it simple, it seems lke webpack does that way too.

[stevemk14ebr]

Sure, I proposed both just because I don't see a standard at the moment or anything and those are the two I'd expect library authors to 'guess' at. One or the other would certainly be better than none!

[poyoho]

this mean is if work in node, we should export node worker?

const worker = require('worker_threads');
export default new worker.Worker(...)

[bluwy]

I think if a package export node workers, it would be nested within a node and worker condition, if they choose so.

[cesutherland]

Here's an example package where I ran into this issue: https://github.com/wooorm/decode-named-character-reference/blob/main/package.json#L32-L40

Configuring resolve.conditions as described above sorted the worker for me (https://vitejs.dev/config/shared-options.html#resolve-conditions), but then both WebWorker and browser assets are built using the worker condition if that's available.

Is there any solution for that, aside from using a separate vite config for the worker?

[davidmyersdev]

I've run into the same problem described by @cesutherland. Is it possible that resolve.conditions could be made unique per environment? Is this something the new Environment API might help solve?

[sapphi-red]

Quoting a comment in #20230 here:

In dev, Vite currently handles modules imported as workers or imported from workers in the same way as if they were imported from normal modules. This is because there were no way to detect whether a module was imported from a worker or not. But now that the Sec-Fetch-Dest header is available, we can detect that a module is imported from a worker. With that we should be able to process modules imported from workers differently from modules imported from normal modules.

After that is implemented, we can add resolve options that are specific to workers or add worker condition by default (#7439). https://github.com/vitejs/vite/issues/20230#issuecomment-3047423096