Set aside CLI option to allow forwarding config options to dynamic .eslintrc(.js/.cjs) files

The version of ESLint you are using.

6.8.0

The problem you want to solve.

I have to create separate configs to tweak portions of the config according to my run-time interest.

For example, if I wanted to just check for security-related rules, I’d have to make a separate config (“security” would be a nice fix-type incidentally). While the configs are modular, it requires manually creating extra configs for each permutation–one with the feature, one without, one with both this and that feature but not that feature, etc.

Or to auto-generate some complicated options (I’m thinking of the likes of blocking all global variables except those whitelisted, such as in this example which whitelists only a and b as an argument to the no-restricted-syntax rule: VariableDeclaration > .declarations[type="VariableDeclarator"][id.name="a"],VariableDeclaration > .declarations[type="VariableDeclarator"][id.name="b"]). I currently have to build this rule by hand or create my own rule which wraps the logic.

Your take on the correct solution to problem.

The simplest solution would be just to reserve one option such as --config-options and fail to err upon encountering it. Then config files could just check process.argv and handle it this way. It might look like --config-options="option1=val1,option2=val2" similar to how Mocha does --reporter-option(s) (https://mochajs.org/#command-line-usage and https://mochajs.org/#-reporter-option-option-o-option-reporter-options-option ).

Alternatively, one could allow JavaScript-based config files to optionally export a function which will be passed an object based on an extra CLI argument.

Are you willing to submit a pull request to implement this change?

Possibly, yes.

[brettz9]

My plate is quite full at the moment, but I can hopefully get to that. Have put it on my to-do list!

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