Add type option to Worker constructor

[aduh95]

This PR adds a type option to the Worker constructor, inspired from WorkerType in HTML spec, and support for data: URLs.

• When eval is true OR filename is a data: URL object, the type option explicitly tells Node.js what kind of JS to expect (ESM or CJS).
• Otherwise, the option is ignored and the usual file extension rules is used.

// use ESM loader to load the worker.js file
new Worker('./worker.js', { type: 'module' });

// eval ESM
new Worker('export default import.meta.url', { eval: true, type: 'module' });

// data: URL
new Worker(
  new URL('data:text/javascript,export default import.meta.url'),
  { type: 'module' }
);

Note: new Worker('./worker.cjs', {type: 'module'}) would load worker.cjs as ES module and new Worker('./worker.mjs', {type: 'classic'}) would load worker.mjs as CJS. I don't expect anyone to have a use-case for this edge-case, but I wanted to clarify it's a possibility with this PR's implementation. This has been reverted based on this PR's comments.

I had to tweak some internal functions, I have put those changes in separate commits to make reviewing them easier.

Fixes: #30682

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[aduh95]

Fixes #30682 btw

[MylesBorins]

This seems reasonable to me. I've added to the modules agenda for visibility

[guybedford]

It would help to understand a driving use case for needing this feature (by that I mean exensionless workers).

We don't have a problem with the fact that extensionless files cannot be imported from ES modules, so I'm just wondering why workers should be different.

[guybedford]

Also I'm wondering if worker evaluation might be achieved with data URIs?

[aduh95]

We don't have a problem with the fact that extensionless files cannot be imported from ES modules, so I'm just wondering why workers should be different.

Maybe should split this PR so we can discuss the two issues separately? My thinking was to make Node.js worker implementation closer to the HTML spec when using type option, and give users a way to shortcut the extension checking.

[aduh95]

After digging a bit more, it turns out the implementation is sloppier than I first imagined. I'll be waiting on modules team feedback if we need/want the actual feature before putting more work into it.

If we want to move this forward, I think I could benefit a lot from the changes on #31229, so maybe wait for it to land, then implement the feature requested on #21667, which could be used for a cleaner implementation.

[hybrist]

Note: new Worker('./worker.cjs', {type: 'module'}) would load worker.cjs as ES module and new Worker('./worker.mjs', {type: 'classic'}) would load worker.mjs as CJS.

That sounds like this circumvents the type detection entirely which isn't compatible with what the web equivalent does. Think of the file extension as our de-facto content-type header. On the web, type: 'module' wouldn't run a resource with content-type: application/node as a JavaScript module.

I think the type option still makes sense to chose the module system (require by default, import when type is set to module). But I don't think it should affect content type resolution.

[bmeck]

We could use a type assertion instead, which seems to be the difference of as (which asserts the type of a target from link tag / module attributes proposal) and type (which changes the loading system of a target).

However, per things like #31388 which was brought about by extension-less support; we probably want to think about how this would expand in the future for formats outside of JS itself. I think if people were uncomfortable with type: 'wasm' in package.json it likely would be argument against using a type field in the constructor here as well.

Since the ESM loader does support data:, and "bin":{"foo":"bin/foo.cjs"} within package.json can point to a file with an extension it might also just be prudent to not do anything except having a switch to select the loader used for the initial worker endpoint; this is similar to how shouldUseESMLoader works

node/lib/internal/modules/run_main.js

Line 23 in f5ef7cd

function shouldUseESMLoader(mainPath) {

in a dynamic manner and wouldn't appear to cause any new forms of conflicts where resources can be interpreted in multiple different ways.

[addaleax]

@aduh95 This looks like it needs to be rebased.

@nodejs/modules-active-members Should this go ahead? It seems good to me.

[bmeck]

We likely should not land this yet. Discussion of expanding to handle the non-JS cases isn't ironed out.

[hybrist]

Should this option be called inputType since it's roughly equivalent to --input-type on the command line?

[aduh95]

Should this option be called inputType since it's roughly equivalent to --input-type on the command line?

Should it be restricted to eval: true like the CLI option?

[aduh95]

I have removed the loader selection for this PR to unblock it.

I have also added support for data: URLs as #31760 (comment) suggested.

[aduh95]

Closing this in favor of #34584.