All in for more strict .eslintrc for me (as long as the values are sensible). Makes the code review part easier and makes the code base more coherent.

Only minus the noise in git history and blame, that's a small thing compared to the benefits.

If you have no issues with merging this, I'd then open PRs fixing one rule per PR so we can get to 0 errors eventually. Eslint's autofix feature would work great here where available, like missing semicolons.

With this grunt eslint and npm run eslint will do different things.
Could you simply define "eslint": "grunt eslint" without adding the .eslintignore file?
As @petetnt I like stricter ESLint checks.

@ficristo my brackets-eslint extension understands official .eslintignore but can't get this stuff from grunt, that's why I opted out for this file. Maybe we can do this the other way, fix grunt eslint to use .eslintignore ?

Ok, this looks better:

$ npm run eslint
> Brackets@1.9.0-0 eslint C:\dev\brackets
> grunt eslint
Running "eslint:grunt" (eslint) task
Running "eslint:src" (eslint) task
Running "eslint:test" (eslint) task
Done, without errors.