Open RedYetiDev opened 3 months ago
Why not just NODE_OPTIONS= node index.js
?
Yes, that works when inline environment variables are supported, but in other cases those aren't supported, or are hard to implement.
I'd like to know more about the use case where node is executed with arbitrary environment variables, and what makes NODE_OPTIONS
more special than other variables that control node's behavior.
AFAIK, there are several cases where the environment variables aren't in the users control, such as with https://github.blog/changelog/2023-10-05-github-actions-node_options-is-now-restricted-from-github_env/.
@RedYetiDev @MoLow @targos Hi, I was wondering if this feature still being considered for implementation? If so, would it be appropriate for a new contributor to work on this? Are there any specific concerns or considerations I should be aware of regarding this proposal? I'd be happy to take this on as my first contribution if it's deemed valuable and if guidance could be provided. If not, I'm open to other suggestions for where a new contributor might be able to help. Thank you for your time and for maintaining this project!
I think I see why GH disabled this in Node in order to prevent people from fiddling around with the options passed (probably) to their Node execution, but I can't recall any possible way that this would be a problem for an end user. In this specific GitHub case I'd say that disabling this variable could possibly cause issues in the execution (is this something that could happen?)
What is the problem this feature will solve?
Currently, in Node.js, a user can define CLI arguments from the
NODE_OPTIONS
environment variable, but sometimes this can lead to some security concerns, when Node.js is used with arbitrary environment variables.What is the feature you are proposing to solve the problem?
I propose a new CLI argument,
--disable-node-options
which will preventNODE_OPTIONS
from having any affect on the CLI arguments.What alternatives have you considered?
No response