Proposal: Conditional rules based on the environment

What version of ESLint are you using? 2.13.0

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

Hello, I have a scenario where I would like to have different .eslint rules when developing locally on my machine than when it’s time to submit the project. Here is how eslint is currently useful to me for local development: As part of the build process, we run something like (simplified): rm -rf dist/ && eslint app/js && browserify app/js/index.js

The nice thing about this setup is that the build fails if eslint doesn’t pass, so I don’t spend time debugging or testing code that is bad in some way. This is mostly goodness, except for when I want to debug something using banned rules. A couple of classic examples are no-constant-condition and no-console. What I want is to be able to say: Have two configs: The main config, and then a few modifications for local development.

Currently, as far as I can tell, I have to have separate config files and pass them in the command line. This is sub-optimal because the rules are in different places and it is not easy to extend off a rule. As far as I know (I may be wrong), I have to essentially copy/paste the .eslintrc and then make the modifications I want for the dev version.

My proposal is to add conditional rules in the form of env:[your environment here]/[rule] For example, I would create this .eslintrc:

no-constant-condition: ["error"],
env:dev/no-constant-condition: ["warn"],

Which would allow me to place both variants side-by-side and then to trigger the code would be eslint --env dev which is easily configurable by build scripts.

I have a local modification to eslint which accomplishes this, and I am happy to drive the fix to mainline if folks like the proposal. This is my first time working with this project so I would appreciate patience and help getting it in.

[ilyavolodin]

@AnilRedshift you actually can extend from local files. And that’s what I would suggest to do. Create base config file, then create 2 config files per runtime environment and extend base in each one of those. Run ESLint with -c flag. Or just create a single config file and mark all of the rules that you don’t want to fail prod build as “warning” instead of “error”.

[alberto]

Thanks for your interest in improving eslint. Unfortunately, it looks like consensus couldn’t be reached on this issue and so I’m closing it. 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 consensus after 21 days tend never to reach consensus, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.