22

Here's a motivating example: I am developing some code and want to figure out what's going wrong, so I have

function foo() {
    console.log("Look its 2016 and I'm still printf debugging");
}

Except... our build process runs esLint as part of the build system and by-design prevents even running the rest of the build pipeline if esLint fails. error Unexpected console statement no-console

What I effectively want is to set up a dev environment where certain rules are turned off (or converted to warnings), and then a production environment with the strict rules turned on. And I want to be able to easily toggle that locally so I can verify my code works before submitting it to a CI server.

I can't find any relevant code snippets to make this happen, which makes me sad. My build environment is just npm scripts (just using the esLint CLI + package.json), but I would be happy to port a solution from another build environment.

Right now, I'm left with either // eslint-disable-line or locally modifying an .eslintrc file and praying I never accidentally check that in by accident. There must be a better way.

AnilRedshift
  • 7,937
  • 7
  • 35
  • 59

3 Answers3

25

Branch your rules by NODE_ENV

You can use .js version of eslint config (eslintrc.js) and branch your rules based on NODE_ENV variable.

In eslintrc.js:

rules: {
 
  'no-console':
    process.env.NODE_ENV === 'production'
      ? 'error'
      : 'warn'

}

Scripts in package.json:

"scripts": {
  "lint": "eslint",
  "lint:prod": "NODE_ENV=production eslint"
}

You will use one version of the rule and your CI the other (assuming NODE_ENV on your CI is set to production).

exmaxx
  • 3,252
  • 28
  • 27
9

From a related thread on github: https://github.com/eslint/eslint/issues/6460#issuecomment-226967834

It looks like what I am going to do is make a dev.eslintrc or similar and have that extend the main .eslintrc. And then I can use command line args to switch between the two rulesets as needed.

AnilRedshift
  • 7,937
  • 7
  • 35
  • 59
3

Why not use pre-commit hook where your code gets checked before any commit happens. You can always disable any rule you want using a comment if local or using .eslintrc file.

Look at https://github.com/jhurliman/precommit-hook for more info. I honestly think all of this need to be development dependency. Your production should not run any lint.

Finally I would add some task runner like grunt or gulp, this way you are able to run your lint, unit tests and any other sanity checks you need for your code.

irimawi
  • 368
  • 1
  • 9
  • A pre-commit hook is hard because it's not easy to push it down to an individual machine without some cp hooks .git/hooks. I would rather just add some shell script that had a .eslintrcdev and .eslintrcprod and copied one or the other to .eslintrc as needed. I'd like to avoid getting into a political discussion about task runners. Just to clarify in case it was misunderstood: we *are* using a task runner of make + npm + node as needed. – AnilRedshift Jun 18 '16 at 04:26
  • I think what I ideally want is to do something like being able to run `eslint --env dev ...` or `eslint --dev prod` (which is supported today), but then have rules in my eslintrc that look something like this `dev/no-console: ['off']` which is not supported. Regardless of if someone has a clever way of solving this, I'm going to see if I can get that feature into eslint. – AnilRedshift Jun 18 '16 at 04:29