Html5-boilerplate: RFC: Migration to ESLint

Anyone? I'm content to leave the status quo. ESLint is great, but I'd need to be convinced to make the change (and then someone would have to _make_ the change in a PR.) I'll leave this open for another week and if there's no action I'll close.

I can PR for this. ESLint is arguably one of the most widely used tools in the javascript ecosystem.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen I'm totally at @amilajack's side on this,
I made a brief comparison between the two with some data I gathered from the Web if you wanna to take a look. It's a gist, click me

Thanks guys. That's great stuff. Anyone else want to chime in?

@amilajack thanks for the offer to PR. It's really appreciated.

@roblarsen You're welcome!
@amilajack Feel free to message me if you come to need any help. :construction_worker:

@amilajack Are you still working on this?

@ryzokuken There's an open PR that I need to take a look at and merge in. #1930

I'd recommend to look into Standard which is addition on top of ESLint, and quite popular one. To be honest, it as relief for use to finally stop maintaining ESLint configs...

@ArmorDarks Even though I like the Standard style, I don't think it's good to enforce others to follow it. Especially developers without much knowledge or experience, as their code may lead to unexpected runtime errors and cause further problems, even leading to increased number of issues for the project.

As much as I like programming language's flexibility, such perk comes at a price, and the question is if we're willing to pay that price. Stricter rules almost always make the code easier to understand and more reliable as a consequence, even as the project grows.

Moreover, semicolons win by popularity, taking Airbnb's JavaScript style guide as an example: one of the most starred repositories on GitHub and higher download numbers on NPM.[1][2][3][4]

Also, we would need to update all JavaScript files, as they're all using semicolons already.[5][6]

Therefore, I don't believe this subject worth the bikeshedding.

References:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

That all will boil down to codestyle disputes anyway. I'm just proposing battle-tested alternative.

Btw, I should highlight, that no matter with what option boilerplate will go (be it ESLint with project's own rules, be it popular ESLint config, like airbnb, or be it Standard), _it will anyway enforce something on users to follow_. So it's just a matter of what exactly will be enforced.

At this point I want to switch to eslint with the least possible interruption. That includes blowing away the existing rules we have in place wholesale without at least a discussion of what new rules should be (which is why the existing PR for eslint is DOA.)

I will die on the hill of semicolons, for example.

As a note: the actual consumers of the ruleset is limited to the maintainers and anyone who is conscientiously creating PRs and actually testing their code. We won't ship an eslintrc in the dist. The real benefit, in terms of the project, is that we _do it_ and can serve as an example of what good web dev should look like.

I will die on the hill of semicolons, for example.

That's just few strokes with regex, you know. But whether use them or no for some people indeed seems to be painful theme...

We won't ship an eslintrc in the dist. The real benefit, in terms of the project, is that we do it and can serve as an example of what good web dev should look like.

But you ship the JS code, which will be included in other projects, which will later be linted, and people will be forced or to edit it to fit their rules, or to use HTML5Boilerplate rules. That's why JS should be as close to JS community standards as possible, and I think that making some necessary changes to rules and codestyle is unavoidable. And not that problematic, really — Standard and ESLint with --fix will automatically fix most part of introduced rule error.

The real issue is what to consider community standard in JS world.

Good points. It's good to be reminded of the downstream effects of even the small amount of JS we do ship.

And to clarify I'm not against making changes. What I don't want to do is make wholesale changes without discussion (so thanks for being part of the discussion 👍 ) While I'm rather desperate to get 6.0 out the door right now, I'm generally in no rush to make changes here unless they're the right changes.

One option is to apply the eslint:recommended config which reports common problems, but doesn't really impose stylistic preferences. In that case, ESLint would just serve to prevent errors and bugs. It really is a kind of minimal, common sense config.

The only style-related rules I would propose to add in that case are the ones present in your .editorconfig: no trailing whitespace, 4 space indents, and final newlines.

4 space indents

Just for the information, none of the popular code styles using 4 spaces indents anymore.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment-377298563 (eslint:recommend) sounds good, although I have a personal preference for https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment-318050971 (StandardJS).

Jokingly: https://github.com/christophwitzko/semicolon-indent#semicolon-indent

I'm with Standard too, because they not only maintain good config with validation through the community but also shipping excellent tested additions on top of the ESLint.

But just to be fair, I should also mention Prettier. Though, my vote still stands for Standard.

Reminder from earlier in the discussion

I will die on the hill of semicolons, for example.

Imagine that it's surviving game, and like we're in the 2005 year deciding on tabs vs spaces.

Btw, worth mention the thing about Prettier — it should be paired with good ESLint config, because mostly all Prettier maintains is code style, while ESLint configs (and especially Standard's one) covering also a lot of non-stylistic good or bad practices.