feat: worker format with worker type

[poyoho]

Description

fix: #8466

Additional context

1. support import worker from worker.js?worker&format=esm
2. support import worker from worker.js?worker&format=iife
3. worker query dts

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

I fear this may be going too far. Is there a way to support the use case without exposing this?
Maybe there could be an option that instead of generating only one format for the workers, it will start generating both es and iife and automatically load the right one depending on the browser? Kind of like plugin-legacy but for workers.

[poyoho]

@patak-dev is need to output two format chunks? In fact, two workers can be exported, and users can choose what they like. The remaining workers will generate files but have no code at runtime(clean it by tree-sharking)

// when config `worker.format: all`
export function esmWorkerWrapper() {
  return new Worker(url)
}

export function iifeWorkerWrapper() {
  return new Worker(url2)
}

The disadvantage is that it need to build a worker twice and emit the unused worker

[poyoho]

I think the url options we can replace like this

import worker, { url } from "./worker.js?worker"

worker.js?worker

export const url = "..."
export default function WorkerWrapper() {
    return new worker("url", {type: "module"})
}

[poyoho]

And use this plan to judge whether the worker needs to be an inline worker #7352 (comment)

[patak-dev]

Would you expand a bit more on the proposed changes in your last comments?

[poyoho]

now I think we can remove all current url query, and then make the content of the url query export by default. (rollup tree-sharking can remove the extra content.)

1. about url we can export direct. Because it has no extra performance overhead.
2. about inline worker we can export it by base64 if it filesize less than worker chunk limit and format by iife. or not we can export it default.
   Because it may have a little extra performance overhead. (sourcemap and base64 strings)
3. about differe worker format differe feature, I prefer to specify to the user. It may be that I don't fully understand what your suggest.

I think the url query syntax we provide is best to have only one level, and the others are exported by default through the virtual module. now it seems just worker work combine multiple query options. 😁

[patak-dev]

Oh, I see, that is an interesting idea. Maybe something to explore in v4 once we also remove the query in favor of as 'worker'? Something that I like about it is that as only lets you specify one string and not more options, so it may be a way for us to avoid that.
This should also be used not only for workers, and I don't know if it is always possible though. For example in CSS, the ?inline will avoid the side effect of adding the styles so you can't do the same trick there, but maybe that is a special case. It also feels a bit strange that we would potentially allow users to import the worker, the url, and the inline string all at once.

[poyoho]

I think index.css will like this.

export const inline = 'css code'
export default 'css url'

in v2 we import the internal module like

import indexCSSURL from "./index.css"
import indexCSSRaw from "./index.css?inline"

import worker from "./worker?worker"
import workerURL from "./worker?worker&url"
import inlineWorker from "./worker?worker&inline"

in v3

import indexCSSURL ,{ inline as indexCSSRaw } from "./index.css"
import { url as workerURL, inline }, worker from "./worker?worker"

However, a big problem is that these strings are stored in memory, which may occupy a very large memory

[patak-dev]

import indexCSSURL ,{ inline as indexCSSRaw } from "./index.css"

This one won't work because when you use the ?inline you are preventing the side-effect of automatically applying the style to the app.

[poyoho]

oh, I see. ?inline makes it a virtual module. I think this method can reduce the request parameters of the virtual module

[poyoho]

But now it seems that url, raw, inline are virtual modules based on vite, and they remain as they are, which is easier for users to accept. ?format is an unique to workers that can be confusing.

IIUC, your suggestion is according to the worker type we collected to interpret the format mode.
type: module -> format: esm. type: classic -> format: iife.

[rockwotj]

Related here is: #7163

I'd love the ability to just get the URL and format for a another bundle. The annoying thing about the current v2 API today is that I cannot easily reuse it for a service worker, because the URL is hidden.