lib: add late code injector

[RaisinTen]

Fixes: #37440

[Trott]

Should this be documented? Does this need a test?

[RaisinTen]

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

[addaleax]

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

[jasnell]

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

[gireeshpunathil]

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.

[devsnek]

@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)];
});

[gireeshpunathil]

@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.

[mscdex]

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

[addaleax]

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.

[gireeshpunathil]

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.

[gireeshpunathil]

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.

[mscdex]

@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?

[gireeshpunathil]

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.

[RaisinTen]

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