JavaScript Linters

Open
#22 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
eslint, javascript

Research direction

No project files, tests, or entry points are named. Start by reviewing the linked ESLint and Prettier plugin documentation and the comparison in this issue, then resolve the listed questions about the linter and plugin use. Done means reaching a decision and re-evaluating standardized rules for consistent coding.

Written by the indexing model from the issue text.

Description

developer relations discussion

JSHint

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

ESLint

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

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.

See ESLint's "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.

You can read more about the Prettier philosophy here.

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.

Dominant language
JavaScript
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from donejs/developer-relations

All issues in donejs/developer-relations

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.