I like it. One question.

@edg2s Do you want to update it or should we take over?

Adding reportUnusedDisableDirectives in the config was only added in ESLint 6.3.0. This repo currently only requires version 6.0.1 (via grunt-eslint 22.0.0).

@edg2s We can update ESLint if that helps, I don’t mind including it in a PR.

@edg2s You said before this doesn't work with the currently used ESLint version. Did anything change?

Sorry, I assumed you would update ESLint separately. I can do it here though.

@edg2s I've noticed grunt-eslint has been already updated on master in November, it's just that your branch is based on an extremely old version of master. Can you please rebase over latest master?

Done.

I merged the PR to both master & 3.x-stable and, unfortunately, only afterwards I noticed:

1. This doesn't error but only print warnings; those warnings are silenced by grunt eslint and they get only printed if you run node_modules/.bin/eslint . directly.
2. there's one eslint-disable comment that is legitimate but we still want to keep it - it's above the version definition because in some custom compilations that string may get large and we validate the build jQuery file with ESLint as well.

I'm not sure how to proceed here due to the above. We can catch some things through these warnings but only when calling the ESLint binary directly and we have to ignore at least this one max-len warning.

Seems to be a common-but-not-enough request: eslint/eslint#12703

The workaround they suggest is --max-warnings 0 assuming we don't get warnings we want to ignore.

A couple of options:

1. Remove the directive, and disable max-len in dist/.eslintrc.json
2. Have the build script that swaps out @Version insert the directive (and only if the resulting line is longer than 100 chars).

@dmethvin Their reasoning sounds reasonable. We could work with it only if we pinned our ESLint version so that patch updates don't make our build fail. Currently we have it pinned via package-lock.json but I'd rather have it explicit in the package.json if possible.

@edg2s I'd go for the first option; way smaller complexity. This doesn't resolve the issue that grunt eslint doesn't print the warnings but we can leave that for a separate PR.

Yeah, you would have to use it in combination with max-warnings and version pinning.

Another issue is that grunt-eslint is giving use warnings for files that listed in .eslintignore. In the upstream issue there are some solutions that involve parsing the ignore file, but that can be done more cleanly by just fetching the parsed results from CLIEngine:

src: [ "src/**/*.js", "Gruntfile.js", "test/**/*.js", "build/**/*.js" ]

	// Ignore files from .eslintignore
	// See https://github.com/sindresorhus/grunt-eslint/issues/119
	.concat(
		new CLIEngine()
			.getConfigForFile( "Gruntfile.js" )
			.ignorePatterns.map( p => "!" + p )
	)