Expose process.env.NODE_OPTIONS parser to user land

[Ethan-Arrowood]

What is the problem this feature will solve?

Node.js has an internal parser for correctly parsing and validating the process.env.NODE_OPTIONS variable. I'd like to expose this parser to user land as something like util.parseNodeOptions.

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

The exact parser code is here:

node/src/node_options.cc

Line 1401 in c29d53c

std::vector<std::string> ParseNodeOptionsEnvVar(

The solution should create a new C++ function that accesses the NODE_OPTIONS environment variable from the Environment so that we do not incur an unnecessary serialization cost passing the NODE_OPTIONS from JS.

Calling the function should return the list of strings.

The function should throw any error it encounters during the parsing process.

I will contribute this feature myself soon 👍

What alternatives have you considered?

We required this functionality for a recent bug in Next.js. I was able to solve that issue by manually converting the C++ parser to JS and using that.

The PR introducing the fix: vercel/next.js#65046

The JS parser implementation itself: https://github.com/vercel/next.js/blob/270a9db0567808db5d53e7a18c7be0a4710796e8/packages/next/src/server/lib/utils.ts#L59-L113

[joyeecheung]

Note that ParseNodeOptionsEnvVar only splits the argument string into a vector of strings by whitespaces. It's not a full parser (i.e. doesn't validate and assign values).

[Ethan-Arrowood]

That is okay. I think providing even the consistent whitespace/quote parsing is important. The core of the issue we ran into in Next.js was because we didn't understand the parsing rules for process.env.NODE_OPTIONS.

I'd have to go and look at the code again, but there was something else that was validating the parsed options. That could be valuable to export as well.

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[Ethan-Arrowood]

no longer working on Next.js, so I don't care to champion this. closing.