Support "worker" export condition when ssr.target is "webworker"

[DylanPiercey]

Clear and concise description of the problem

https://github.com/vitejs/vite/pull/3151/files added support for setting ssr.target to "webworker". This appears to set the export conditions to include "browser".

It would be great to be able to detect when compiling to a worker specifically with export conditions but there is no condition currently set for web workers.

Suggested solution

I propose setting a "worker" condition when we target web workers. This would be consistent with webpack (https://webpack.js.org/guides/package-exports/#target-environment).

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.

[patak-dev]

Do you plan to send a PR so we can discuss seeing the needed changes?

[DylanPiercey]

@patak-dev I'd like to make a PR, but I might need a bit of guidance. The code around resolving paths is quite spread out throughout the codebase.

Conceptually I think I'd just hook into https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/resolve.ts#L784

and add

  if (options.ssrConfig?.target === 'webworker') {
    conditions.push('worker');
  }

However we only want to add the worker condition if we are doing an ssr resolve and I'm not sure if I have that information at that point.

[bluwy]

A similar feature request #7439

[cesutherland]

Adding worker and webworker to resolve.conditions config as mentioned in #7439 sorted this for me. I agree with that issue that this should be automatic for WebWorkers targets.

https://vitejs.dev/config/shared-options.html#resolve-conditions

[manucorporat]

Also hitting us with trying to use react with emotion in Qwik!

[manucorporat]

I think it's a mistake to confuse webworker with browser:

• workers in general might run in the browser but have no access dom browser API like the DOM
• webworker target is usually used to target edge deployment for SSR (ie, netlify, vercel-edge, cloudflare) non of them is a browser setup, but it's not 'node'

webworker might be a bad term that already spans very different APIs. Maybe we should have:

• "browser-worker"
• "browser"
• "node"
• "worker" (edge)

[DylanPiercey]

@manucorporat I think you could still differentiate by using nested export conditions like so:

{
  "exports": {
    "browser": {
      "worker": "target browsers web workers",
      "default": "regular browser import"
    },
    "node": {
      "worker": "worker in a node environment",
      "default": "regular node script"
    },
    "worker": "probably edge?",
    "default": "🤷‍♂️"
  }
}