Add configuration: disallow inline rule configuration

What version are you using? v1.1.0

What did you do? We would like use eslint to help us validate the code inside Firefox Add-ons. We should be able to use eslint to do so, but we’d like an option to ignore inline rules (eg /*eslint eqeqeq:0*/) so our code quality checks can’t be defated by add-ons with inline ESLint comment configuration lines in their JS.

What happened? Right now there is no way (that I’ve found) to allow comments but ignore all inline ESLint configs.

What did you expect to happen? We would like to ignore all inline comments so only the configuration passed to ESLint CLI/library on startup are followed.

I will be working on pull request to this, so if the idea would be accepted inside ESLint I’ll submit.

Thanks for the awesome library, folks 👍

[tofumatt]

Okay, sorry. 😃

Inline things I want to ignore:

• /*eslint-disable*/ and /*eslint-enable*/
• /*global*/
• /*eslint*/
• /*eslint-env*/

Future-proofing?

I want to ignore literally everything.

We might use plugins to extend ESLint for our validator, and I’d want to protect against the plugin and its options being modified/removed too, so my thought is it’s not a subset of options but an option to simply ignore any inline modification of the config state once you’ve parsed everything from:

1. Command line options:
   • --global
   • --rule
   • --env
   • -c, --config
2. Project-level configuration:
   • .eslintrc file in same directory as linted file
   • package.json file in same directory as linted file
   • .eslintrc and package.json files in ancestor directories (parent has highest precedence, then grandparent, etc.), up to and including the root directory or until a config with “root”: true is found.
   • In the absence of any configuration from (1) thru (3), fall back to a personal default configuration in ~/.eslintrc.

---

I think those four things I want to ignore should cover that, but please let me know if there’s an obvious “attack vector” I’m missing.

[nzakas]

Okay, then I think your use case is too different from this request, so we will need to address separately.