Worker eval as ES Module

[targos]

Unless I missed it, there doesn't seem to be a way of creating a Worker from an ESM source string (with eval: true).

Example that should be possible somehow:

import { Worker } from 'worker_threads';

new Worker(
  `
  import { join } from 'path';
  console.log(join('hello', 'world'));
`,
  { eval: true },
);

Related: #21502

[targos]

Adding execArgv: ['--input-type=module'] to the options doesn't help (and wouldn't be the best UX).

[lin7sh]

Can I use Es6 module in Worker by using new Worker("./foo.js", { type: "module" }) Chrome 80 will enable this feature by default https://bugs.chromium.org/p/chromium/issues/detail?id=680046

[addaleax]

@nodejs/modules-active-members

[targos]

@mko-io if your file would be interpreted as a module when run with node foo.js (in a "type": "module" package, or if the extension is .mjs), yes.

[hybrist]

I hope we'll support type: module for workers. I assume in that case we could treat it as an implicit "also treat the source text as .mjs" (as opposed to supporting different kinds of modules in eval: true):

import { Worker } from 'worker_threads';

new Worker(
  `
  import { join } from 'path';
  console.log(join('hello', 'world'));
`,
  { eval: true, type: 'module' },
);

(Not working code, just as a possible example of what it would look like in node.)

[addaleax]

If we do add a type: 'module' option to the Worker constructor, should that also apply to non-eval code, i.e. be treated like a package.json type: option?

[hybrist]

I assume it should only import instead of require (in terms of loading semantics). Generally speaking we've been hesitant to allow the importer to change the static semantics of the imported resource. import-semantics may also imply that the "filename" is a URL (e.g. support for data: URLs).

Since we don't support bare specifiers for workers and we don't support conditional mappings of effectively "absolute URLs", I assume that type: module is mostly opting into an async worker bootstrap but not much else outside of eval.

[guybedford]

Do workers already support the package.json "type": "module" ok? If so then perhaps we don't need type: 'module' as an option at all actually. The major argument for that would be web compatibility but we already don't have web compatibility for this API as a goal right?

Perhaps eval can be supported via either eval: 'module' or using a data URI with a MIME type corresponding to a module like we already support in the module loader as well?

[devsnek]

I think we should try to match the web worker API, which uses type: classic and type: module. lacking URL.createObjectURL, combining type:module with eval:true makes the most sense to me. The collision with the "type" name in package.json is unfortunate but not a huge deal imo.

[guybedford]

The question is - why though?

[devsnek]

why work towards compat with other runtimes? it's annoying and confusing when there's a difference. we also do try to work in compat where possible, like supporting on{event} properties.

[guybedford]

As mentioned Worker is already not web compatible though as it uses paths not URLs and also has API differences. So since a compatibility layer is needed regardless any attempt towards web compat is just "going through the motions", while also invalidating the work we've done that already ensures module types are well-defined.

[GeoffreyBooth]

I guess one question is, could Worker someday be Web compatible? Like we may be lacking URL.createObjectURL right now, but it seems like something we could conceivably add someday, isn’t it? Since we have data URIs already. Likewise we’ve been batting around the idea of import from http URLs, which isn’t possible now but my understanding is that that was mostly punted for difficulty (working out the mechanics of what allowing that would mean) rather than some philosophical opposition.

Anyway my point is, if theoretically Worker might be web-compatible someday once we work out all the other incompatible pieces around it, then we might as well stay compatible whenever possible now, to avoid breaking changes later when the only parts that are incompatible are the APIs we deliberately designed differently. And I agree with @devsnek, it’s a better UX to have the same (or as similar as possible) API for Worker in both environments, if nothing else to help users remember it.