Duplicate errors

[Raynos]

Since your using three linters your tool will report errors multiple times.

We build a deduplicator into lint-trap cc @malandrew

• https://github.com/uber/lint-trap/blob/master/dupe-map.json
• https://github.com/uber/lint-trap/blob/master/dedupe-transform.js

You may want something similar :D #goodluck

[feross]

I'd rather address this by never enabling overlapping rules, i.e. if JSHint is checking that no unused variables exist, then ESLint shouldn't be doing that too. Wouldn't this be a more straightforward way to address the issue?

[Raynos]

@feross I think so. I can't remember why we have a dupe map.

[feross]

Cool. I'll address duplicates as they come up by relaxing the rules. I've already done this for a few rules.

If anyone runs into any duplicate errors, please run standard --verbose and post the output here. :)

[andrewdeandrade]

Dupe map was used because some of the rules were implemented in a subtly different way. Recently, I started removing duplicate rules that I didn't want, and I'm filing issues in eslint to get features into eslint that jscs or jshint have (currently there is only one rule better implemented in jshint versus eslint. one eslint hits parity, I'm going to drop jshint).

The biggest challenge you're going to find with a new linter is not making this project, but building out all the code editor support (SublimeLinter, syntastic, flycheck, etc.). That was the biggest barrier to adoption by co-workers.

Anyways, I'd say to just use lint-trap, but you're probably not going to agree with some of the style choices we made.

[feross]

once eslint hits parity, I'm going to drop jshint

Excellent! I'll drop jshint at the same time. Which rule is currently better implemented in jshint?

[feross]

I just removed JSHint entirely. I couldn't find any cases where it caught issues that ESLint missed.

There don't appear to be any more duplicate errors. If anyone notices a duplicate error, please open a new issue.