Allow `npm_config_*`-style params for `no-process-env`

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

[brettz9]

@ljharb : Sorry, I don’t follow what the difference is. I am able to read npm_config_* vars from process.env.npm_config_* (e.g., such as process.env.npm_config_test) merely by passing in the argument to npm, 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#config

[eslint-deprecated[bot]]

Unfortunately, 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.