Should this be documented? Does this need a test?

@Trott yes, will surely add documentation + tests for this after setupLateCodeInjector works as expected.

In the current form, this should definitely be implemented in userland through NODE_OPTIONS=--require=... instead

Yeah, without more information about the specific set of use cases being targeted here, I have to agree with @addaleax

In the current form, this should definitely be implemented in userland through NODE_OPTIONS=--require=... instead

@addaleax - how does that work? with --require, the module should be present at startup right? my use case has node process predates the module. In theory, the module can be developed even after the production has started.

@gireeshpunathil at startup, load a small module loader script, instead of the main script:

'use strict';
process.on('SIGUSR1', () => {
  require(process.env.THE_MODULE);
  delete require.cache[require.resolve(process.env.THE_MODULE)];
});

@devsnek - makes sense, in the given premise of this PR ( there are certain preparation possible prior to the process launch). However, the original issue does not have such a premise. How do we run an arbitrary piece of code in a running process, where the process did not undergo any preparatory steps.

This PR is probably a middleground approach wherein the name of the module is set on the env , but probably that is coming from an implementation challenge of:

• unable to export env data after startup
• unable to pass data through signals

, not because we have that flexibility.

If you want to run arbitrary code after launch, why not start a tcp server in conjunction with repl and/or readline?

This PR is probably a middleground approach wherein the name of the module is set on the env

I wouldn't call this PR a midde ground, though, because it has the exact same set of requirements as what @devsnek and I would be suggesting. If you want a no-preparation-at-all scenario, then you'll need a different approach.

If you want to run arbitrary code after launch, why not start a tcp server in conjunction with repl and/or readline?

@mscdex - that needs the target process to be prepared for receiving an arbitrary code, right? Here is my requirement, restating:

Run an arbitrary piece of code in a running process, where the process did not undergo any preparatory steps.

If you want a no-preparation-at-all scenario, then you'll need a different approach.

@addaleax - yes agree. Please let @RaisinTen / me know if you have ideas on those lines.

@gireeshpunathil It sounds like what you're wanting is impossible then. Even with this PR it requires an environment variable on startup of the process?

Even with this PR it requires an environment variable on startup of the process?

@mscdex - agree, this PR assumes we are informed about a future attach.

Thanks for the reviews. Closing in favour of #37748.