Allow `npm_config_*`-style params for `no-process-env`
See original GitHub issueWhat rule do you want to change?
no-process-env
Does this change cause the rule to produce more or fewer warnings?
Fewer warnings.
How will the change be implemented? (New option, new default behavior, etc.)?
Either as a new option specifically for this form of variable, a configurable option allowing a user-customized pattern to indicate variables exempt from the rule, or a new default behavior specifically for this form of variable.
Please provide some example code that this change will affect:
console.log(process.env.npm_config_test);
What does the rule currently do for this code?
Reports “Unexpected use of process.env”
What will the rule do after it’s changed?
Report nothing.
Are you willing to submit a pull request to implement this change?
Not at this time.
Rationale
As per https://docs.npmjs.com/misc/config#environment-variables , npm has this npm_config_*
means of passing in config through npm scripts. Although it is possible that environments could set these variables, it is more likely that npm scripts are, as designed, passing in this config.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5 (4 by maintainers)
@ljharb : Sorry, I don’t follow what the difference is. I am able to read
npm_config_*
vars fromprocess.env.npm_config_*
(e.g., such asprocess.env.npm_config_test
) merely by passing in the argument tonpm
, e.g.,npm --test=abc test
.This is a documented way to pass in config to scripts, and I’d expect a way to be able to make use of it in ESLint without complaint.
Admittedly, one can also set through
npm config set
which makes it more like a normal environmental variable, but I think this is quite convenient to use exclusively to pass in flags in npm scripts and have the option to make an exception for these kinds of config in ESLint.I also neglected to mention
process.env.npm_package_config_
: https://docs.npmjs.com/misc/config#per-package-config-settings and https://docs.npmjs.com/files/package.json#configUnfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.
Thanks for contributing to ESLint and we appreciate your understanding.