fix(register): do not inherit parent execArgv - #18131

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/61899

Open in StackBlitz

commit: a7f071a

Is this a Node.js bug or intended behavior on their side?

Node.js somehow hangs and the worker does not start.

Error [ERR_INPUT_TYPE_NOT_ALLOWED]: --input-type can only be used with string input via --eval, --print, or STDIN

In this PR we avoid inheriting command line arguments for the babel-register worker, per the best practise mentioned in nodejs.org/api/worker_threads.html#launching-worker-threads-from-preload-scripts.

Amazing! Thanks to this, we can remove both markInRegisterWorker and isInRegisterWorker.

@nicolo-ribaudo wrote

Is this a Node.js bug or intended behavior on their side?

@liuxingbaoyu wrote

Error [ERR_INPUT_TYPE_NOT_ALLOWED]: --input-type can only be used with string input via --eval, --print, or STDIN

Yes, so what's happening here is that Node.js does not pass --eval to the worker but passed --input-type, an error is thrown when the esm loader is loading the worker and the signal does not have a chance to change so the event loop is blocked indefinitely.

Here is a minimum reproduction case without babel-register:

// server.js
import { parentPort, isMainThread, Worker } from "node:worker_threads";

if (isMainThread) {
  const worker = new Worker(new URL(import.meta.url), { execArgv: process.execArgv });
  const signal = new Int32Array(new SharedArrayBuffer(4), 0, 1);
  worker.postMessage({ signal });
  Atomics.wait(signal, 0, 0, 1000);
  worker.unref();
} else {
  parentPort.addListener("message", ({ signal }) => {
    Atomics.store(signal, 0, 1);
    Atomics.notify(signal, 0, 1);
  });
}

node --import ./server.js --input-type=module -e "console.log(0)"

Though it would be great if the error ERR_INPUT_TYPE_NOT_ALLOWED can somehow be captured, either from a worker event or is populated from new Worker(...). Currently the error is only piped to the stderr of the main thread.

Update: so any uncaught error thrown from the worker will emit the error event, but Atomics.wait blocks the loop so Node.js does not have a chance to handle it. I think this is an essential limit of our current wrap-async-within-sync approach.

What we could do is to add a realistic timeout to the Atomics.wait, e.g. 30 seconds or smaller amount, so at least when there is uncaught error during the loading step, the error will eventually show up.