feat: allow worker options via variable

[mame]

Description

This PR allows a variable reference in worker options of new Worker() as follows:

const myWorkerOptions = { type: 'module' }
...
new Worker(new URL(..., import.meta.url), myWorkerOptions)

Background: Emscripten 3.1.58 (or later) generates such a code. I thought about fixing it on the emscripten side, but it would be better if the vite could support this style. See also emscripten-core/emscripten#22394

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sapphi-red]

Thanks for the PR.

Even if we add support for this case, we'll still have many unsupported cases.

const type = 'module'
new Worker(new URL(..., import.meta.url), { type })

const opts = { type: 'module' }
new Worker(new URL(..., import.meta.url), { ...opts, name: 'foo' })

import { opts } from './worker.utils'
new Worker(new URL(..., import.meta.url), opts)

If we keep adding support for these cases, both the document and the implementation will be bloated.
So I prefer to keep it in the current state.

But let's see what others think.

[patak-dev]

I also vote to keep things as is here. It is unfortunate that we have this issue with emscripten, but if it is possible to fix this there, that should be more clear and maintainable for the future. As Sapphi explained, once we open this door, we should probably support a lot more cases or it will be quite confusing.

[mame]

Thank you for your comments. If such a decision is made, I will comply.

I would like you to look at the corresponding generation code of Emscripten:

https://github.com/emscripten-core/emscripten/blob/10cb9d46cdd17e7a96de68137c9649d9a630fbc7/src/library_pthread.js#L396-L462

As you can see, workerOptions is used in 4 places. Inlining the definition in each place would be obviously never “more clear and maintainable”.

I see no need to extend this support unlimitedly. I thought that the style such as var workerOptions could be frequent in the generated code and is worth supporting in Vite. Just IMO.