Freeze NODE_OPTIONS for SingeExecutableApplications

[pipobscure]

What is the problem this feature will solve?

The NODE_OPTIONS environment variable allows configuration of the node process at runtime. This is inappropriate for Single Executable Applications. But the configurability provided is also something strictly desirable foe Single Executable Applications at "build" time.

What is the feature you are proposing to solve the problem?

1. Store the NODE_OPTIONS environment variable into the injected blob at build-time
2. Use that value to override the environment NODE_OPTIONS value at runtime

What alternatives have you considered?

I looked at enabling individual overrides via sea-config.json as well as possibly storing the actual environment settings and reconstructing these.

However that seems to be either less configurable as well as introducing additional complexity. By going this route, we'd expose the full configurability of NODE_OPTIONS while at the same time not introducing any strictly new mechanisms.

[pipobscure]

@joyeecheung I'm happy to do this if you think it's the right thing to do. Just let me know.

I'm looking at this specifically for --experimental-vm-modules which would enable the main sea script to just be a module loader (kept sync) which would allow ESM/CJS/JSON/Native/etc loading for any SEA by just resolving to assets. But that's just my own experimental work.

[RedYetiDev]

Similar issue: nodejs/single-executable#100

[joyeecheung]

It seems to me what you need is just 2 if the SEA configuration JSON file can be used to configure CLI flags and environment variables overrides. Then for 1 you can just generate those fields in the JSON configuration at build time? A special case that only works with NODE_OPTIONS could cause surprises when support for more generic override is added and they don't work together (as requested in nodejs/single-executable#100 and some other SEA issues).

[pipobscure]

Sort of. I need 2 to function but also want NODE_OPTIONS via env variables to be blocked in sea since they change behaviour and therefore make things unpredictable. So maybe I have no issue if you think it's better to put all flags into sea-config.json I'm ok with that if there is a --no-env-options suppirted in that as well.

[joyeecheung]

If it's an environmental variable override, having overrides alone would block the NODE_OPTION coming from runtime (and if it's overridden to an empty string it would just block the runtime values without adding new ones).

[joyeecheung]

I think supporting a config like this in the SEA config might be enough for the use case:

{
  "env": { "NODE_OPTIONS": "--no-warnings" }
}

This is probably equivalent to:

{
  "env": { "NODE_OPTIONS": "" },
  "argv": [ "--no-warnings" ]
}