Fixes #30682 btw

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

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.

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

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.

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.

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.

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

@aduh95 This looks like it needs to be rebased.

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

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

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

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?

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

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

Closing this in favor of #34584.