JavaScript Linters

## [JSHint](https://github.com/jshint/jshint)

Started | Contributors | Commits | Issues | PRs | Plugins?
--------- |------------- | -------- | ------ | --- | --------
2010 | 230 | 1,929 | 337 | 68 | ✘

## [ESLint](https://github.com/eslint/eslint)

Started | Contributors | Commits | Issues | PRs | Plugins?
--------- |------------- | -------- | ------ | --- | --------
2013 | 486 | 5,698 | 209 | 41 | ✔

## [Prettier](https://github.com/prettier/prettier)

Started | Contributors | Commits | Issues | PRs | Plugins?
--------- |------------- | -------- | ------ | --- | --------
2016 | 68 | 645 | 91 | 10 | ✔

# Importance of Plugins

I can imagine some use-cases for a linter that accepts plugins; such as linting the `@tag` code comments that bit-docs supports.

At any rate, I feel this is an important feature to have, and we could probably start making use of it right away.

Both ESLint and Prettier support plugins, but JSHint does not. For this reason, I think JSHint should be taken out of the running; JSHint hasn't discussed adding a plugin system [since 2015](https://github.com/jshint/jshint/issues/2079).

See ESLint's "[Working with Plugins](http://eslint.org/docs/developer-guide/working-with-plugins)".

# Rewriting Files vs. Giving a Warning

Prettier actually rewrites the files that it lints. It takes the JavaScript in the file, parses it into AST, and spits it out.

This in contrast to how ESLint simply gives a warning and leaves the fixing up to you.

Supposedly the AST strategy of Prettier can catch formatting/style "errors", or inconsistencies that ESLint would miss. The example they give is:

```
foo({ num: 3 },
1, 2)

foo(
{ num: 3 },
1, 2)

foo(
{ num: 3 },
1,
2
)
```

Saying this would be missed by other linters, while Prettier would clean it up.

# Maturity

Prettier, started in 2016, comes with a bold warning that it is "beta" and that you should always commit your files before linting them with Prettier, because it rewrites the file and might mess it up:

> To format a file in-place, use --write. While this is in beta you should probably commit your code before doing that.

ESLint seems to be the better option as long as Prettier works the way it does, and as long as it comes with that warning. Prettier also warns that the API will probably change, so you will have to reimplement it a couple times before it stabilizes:

> Warning: This is a beta, and the format may change over time. If you aren't OK with the format changing, wait for a more stable version.

You can read more about the ESLint philosophy [here](http://eslint.org/docs/about/#philosophy).

You can read more about the Prettier philosophy [here](http://jlongster.com/A-Prettier-Formatter).

# Conclusion

Let's discuss:

1. Do you think we would ever use Prettier in the future, once it finally stabilizes?
2. Is it worth switching from JSHint to ESLint, for the main benefit of having plugins?
a. Can you think of any good uses for the plugin system?
b. Can you think of any other good reasons in support of switching?

## Next Steps

Once we've reached a decision, we should re-evaluate what standardized rules we want to put in place for consistent coding.