Support whitelist with `no-implicit-globals`
See original GitHub issueWhat rule do you want to change?
no-implicit-globals
Does this change cause the rule to produce more or fewer warnings?
Fewer warnings when new config is set.
How will the change be implemented? (New option, new default behavior, etc.)?
A new option.
Please provide some example code that this change will affect:
All of the examples which currently report, e.g.,
var foo = 1;
function bar() {}
or for non-strict mode:
foo = 1;
Also for the following when lexicalBindings
is true
.
const foo = 1;
let baz;
class Bar {}
What does the rule currently do for this code?
Reports them.
What will the rule do after it’s changed?
Not report them. E.g., when the rules is defined as /* eslint no-implicit-globals: ['error', {allowed: ['foo', 'baz', 'Bar', 'bar']}] */
Are you willing to submit a pull request to implement this change?
Possibly, yes.
The whitelist is intended to be particularly useful when auditing third-party code, ensuring that it doesn’t set any other globals than are expected (while still allowing it to set some expected globals). However, this could be useful for any project which wishes to avoid accidentally setting globals (while still allowing it to set some and not being forced into the style of setting on window
–which one might wish to forbid separately with no-restricted-syntax
anyways).
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:7 (6 by maintainers)
This is actually the first time I’ve heard of ESLint being used this way, so I don’t think it’s a common use case. It’s definitely cool, though, and I do think it would be better to have a plugin with custom rules. I’m happy to defer to team consensus on this 😃
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.