feat(worker): support dynamic worker option fields

[jamsinclair]

Description

The Problem

Vite has a hard requirement that worker options are defined statically or it throws an error. This prevents some legitimate use cases, such as when a dynamic name is used to differentiate workers. As seen in the Emscripten project (code reference)

worker = new Worker(new URL('target.js', import.meta.url), {
  'type': 'module',
  'name': 'em-pthread-' + PThread.nextWorkerID,
})

This is causing some issues in trying to update Emscripten to support Vite when workers are in use.

Solution

Vite only needs to ensure that the type value is statically defined. Other fields could be dynamically computed with no effect on the Vite bundling process.

A side discussion was started in #18396 (comment) about relaxing the usage of some worker option fields to support this.

This PR hopes to solve this issue in a backwards compatible way that still ensures that Vite can have high confidence in asserting the worker type at compile time.

[jamsinclair]

Looks like this change broke the tests in two ways 😅

• Windows paths aren't resolving nicely with the unit tests
• It seems to have broken the worker integration tests Solved by 7cf1551

I'll look into fixing these tomorrow.

[jamsinclair]

Removing the comment as the options can now legitimately be used as defined.

Should we add any explicit tests in the playground or will this suffice?

[sapphi-red]

It seems this was added by #7099 and looks fine to simply remove the comment 👍

[sapphi-red]

Thank you! I left some minor comments.

[sapphi-red]

We statically import rollup/parseAst in other places so let's do it here as well.

[sapphi-red]

Suggested change

	const optsNode = ((await parseAstAsync(`(${rawOpts})`)).body[0] as any)
	.expression
	const optsNode = (
	(await parseAstAsync(`(${rawOpts})`))
	.body[0] as RollupAstNode<ExpressionStatement>
	).expression

Let's add some types to make it safer.

[sapphi-red]

Suggested change

	astNode: any,
	astNode: Expression,

[sapphi-red]

Suggested change

	if (property.type === 'Property' && property.key?.name === 'type') {
	if (
	property.type === 'Property' &&
	((property.key.type === 'Identifier' && property.key.name === 'type') ||
	(property.key.type === 'Literal' && property.key.value === 'type'))
	) {

I think we can add support for { "type": "module" }. It would be nice to have a test for this one.

[sapphi-red]

Suggested change

	if (typeProperty?.value?.type !== 'Literal') {
	if (typeProperty?.value.type !== 'Literal') {

I guess this ? is not necessary.

[sapphi-red]

Suggested change

	// @Note copied from packages/vite/src/shared/utils.ts
	const windowsSlashRE = /\\/g
	function slash(p: string): string {
	return p.replace(windowsSlashRE, '/')
	}
	async function createWorkerImportMetaUrlPluginTransform() {
	const root = slash(path.join(import.meta.dirname, 'fixtures/worker'))
	const config = await resolveConfig({ configFile: false, root }, 'serve')
	const instance = workerImportMetaUrlPlugin(config)
	const environment = new PartialEnvironment('client', config)
	return async (code: string) => {
	// @ts-expect-error transform should exist
	const result = await instance.transform.call(
	{ environment, parse: parseAst },
	code,
	path.join(root, 'foo.ts'),
	)
	return result?.code || result
	}
	}
	async function createWorkerImportMetaUrlPluginTransform() {
	const config = await resolveConfig({ configFile: false }, 'serve')
	const instance = workerImportMetaUrlPlugin(config)
	const environment = new PartialEnvironment('client', config)
	return async (code: string) => {
	// @ts-expect-error transform should exist
	const result = await instance.transform.call(
	{ environment, parse: parseAst },
	code,
	'foo.ts',
	)
	return result?.code || result
	}
	}

It seems we can now simplify this and align with assetImportMetaUrl.spec.ts.