Using standard code style

[dougwilson]

This is a new discussion to live by itself stemmed from the comment at #14 (comment)

The idea is to apply eslint to our repos to help guide contributors and make it less confusing on what style to use. @LinusU suggested "standard" (http://standardjs.com/) and the style, and of course, I don't think everyone will agree with all aspects of the style, but after a lot of research, I tend to agree a vote for "standard" sounds fine to me. I found the following arguments for using standard:

1. It's a set of rules with the philosophy of "no configuration", which means we shouldn't debate about any code styling after adopting it, which wastes time.
2. When standard makes major changes, they pull down all repos using the standard style and run the liter against them to see what fails. This sounds good since it should mean we rarely will have an upgrade where we have to fix a bunch of over code to the new style :)

@LinusU please share any thoughts you have as well.

I have already converted a bunch of jshttp organization repos to this style, at least for the repos that were pretty much literally this style before, so there wasn't any real conversion anyway.

[LinusU]

I think it's a very good idea to move to standardjs, pretty much for the same two reasons that @dougwilson mentioned. I've started using them in all my projects since it helps to enforce a consistent coding style which absolutely helps when reading the code.

It also catches some programmer errors, such as accidentally leaking global variables, which is very good with many people contributing patches.

As already said, it's extremely easy to install and maintain, since there is no configuration and all upgrades are tested on the entire eco system.

Having standard as part of npm test helps eliminates unnecessary discussions about following the existing coding style on pull requests.

I'm all for implementing it, and would be happy to submit pull requests to do it 🙌

[hacksparrow]

+1 for standardjs.

[blakeembrey]

Sounds great. I've been using it for a year or so now, including on path-to-regexp (since I was deviating from the jshttp style accidentally at that point).

I'll need to update it to use the ESLint style configuration from our call today.

[dougwilson]

So here is an example of a commit I've made that sound help: expressjs/morgan@1533cdc

Of note are the following changes:

• Added a .eslintignore file, mainly to keep eslint from linting any generated coverage/ directory.
• Added a .eslintrc file, just specifying the standard style.
• Added npm run lint to the CI commands to run, specifically after the actual tests, such that it is easy to tell if a PR, even though it fails linting, passes the actual tests.
• Added devDependencies and a simple eslint command to package.json.
• Added a test/.eslintrc file for the mocha tests. Technically this can be a comment in the file, but ¯\_(ツ)_/¯

[jonathanong]

why not just run "lint": "eslint lib test" and forget about the .eslintignore file?

or eslint index.js test in this case

[dougwilson]

I tired that, but it mostly came down to editors. I had an editor that would let you run a report on your project and fix with eslint automatically, but as soon as I did the test coverage, it of course tried to do all this on those JS files from Istanbul output :(

[dougwilson]

We're using Standard JS !