Remove extension check on Workers since they can run with require extensions

[CyriacBr]

Is your feature request related to a problem? Please describe.
Currently workers can only run ".js", ".mjs", or ".cjs" files. However, you can pass them, through execArgv, a preloaded module to handle any other extension. This is the case with babel-register or esbuild-register, allowing node to run ts files on the fly. node -r esbuild-register foo.ts.

This would work if it weren't for the extension check:

const { Worker } = require("worker_threads");

const worker = new Worker("./test.ts", {
  execArgv: ["--require", "esbuild-register"],
});

Describe the solution you'd like
Maybe the current extension check is not needed, or should be able to be manually disabled through an option.

Describe alternatives you've considered
A workaround is to monkeypatch path.extname to masquerade your worker file as .js file. While it is obviously inappropriate, it shows that everything indeed works without any extension check.

const path = require("path");
const oldExtname = path.extname;
path.extname = filename => filename.endsWith('test.ts') ? ".js" : oldExtname(filename);

const { Worker } = require("worker_threads");

const worker = new Worker("./test.ts", {
  execArgv: ["--require", "esbuild-register"],
});

[targos]

@nodejs/workers

[benjamingr]

This sounds reasonable to me (the current workaround of just going through an intermediate file is fine but this is a reasonable ask)

[macarie]

I was going to open an issue, but I've found this one, and I think it's a similar scenario.

In my case, I was playing around with ESM loaders, everything works fine until you try to run a .ts file through a Worker.

I've made a demo https://github.com/macarie/esm-loader-worker; to run it use node --experimental-loader ./loader.js ./index.js --file ./javascript.js and node --experimental-loader ./loader.js ./index.js --file ./typescript.ts.
Both files, javascript.js and typescript.ts, import a TypeScript file, fib.ts, but only the first one runs. Using @CyriacBr's workaround, both of them work.