Option to disable inline global declarations

Tell us about your environment

• ESLint Version: v3.19.0
• Node Version: v6.10.0
• npm Version: 3.10.10

What parser (default, Babel-ESLint, etc.) are you using? babel-eslint

The problem you want to solve. Disallowing developers to introduce new globals.

ESLint allows two ways of specifying global variables—setting globals in a configuration file and as a comment in a JavaScript file /* global var1, var2 */.

http://eslint.org/docs/user-guide/configuring#specifying-globals

Your take on the correct solution to problem While globals are sometimes necessary, I’d like to be able to only allow globals that are specified by the globals in a config file and not as comments inside a JavaScript file. The reason for this is that we have a large codebase and we’d like to be able to enforce which globals we allow at a top level without allowing individual developers to be able to override this in their own files. While we can do this by making sure people don’t change the .eslintrc file it’s harder to watch for people doing /* global var1, var2 */ in a file.

I noticed this issue the other day when someone was porting some code that contained /* global jq */ to a place where jQuery was not defined on the global scope and thus ESLint didn’t help with catching this.

Of course I can use a different tool or a custom ESLint rule to disable comments like /* global var1, var2 */ but it would be nice if this could be included natively as part of ESLint.

I’m unsure the best way to do this. Intuitively it makes more sense to me for this to be an option to no-undef but given that this logic appears to be handled well before the code in no-undef is even run it might make more sense to happen in the configuration file.

[platinumazure]

@ljharb In general, I take your point; however, one could manage CLI options per project using npm scripts in package.json.

That said, I wouldn’t be opposed to leveraging optionator to expand inline-config to support key/value options to augment its current Boolean mode. Might be worth creating a separate issue?

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement a rule yourself to disallow /* global */ comments, rather than using core behavior that is packaged with ESLint.