Hacker News Reader

Comment by blatantly | Hacker News Reader

I'd forgive a few of those. Unicode is Unicode. The for loop capture behaviour makes sense to me. Missing semis should also be in your linter. Sparse arrays is the sort of feature you'd read up on if you use and not rely on intuition. It makes sense that if you loop over a sparse thing the looping is sparse too.

View on HN

Since I started using Prettier, I've moved permanently into the no-semicolons camp. Prettier catches ASI hazards and inserts semicolons where needed, and I've never seen it fail. Whichever camp you're in though, put it in your linter, don't leave it to chance. React code is full of array destructuring, that particular hazard is prone to bite you if you ignore it (tho it's still a little contrived if your usual style is avoiding mutable variables).

I can't think of any typical case where you're destructuring arrays in React without const/let.

The only time you start a line with a delimiter in JS that I can think of is a rare case like `;[1,2,3].forEach(...)` which also isn't something you do in React.

While I still hate semis, these days my approach to formatting is just `echo {} > .prettierrc` and using the defaults. It's a nice balance where I never write a semicolon myself, and I never have to dick around with config.

The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis.

That's it, those are the only 2 edge cases.

No, there are quite a lot of other edge cases. E.g. you also need them before backticks and in many places in class bodies.

Instead of learning a rule and then memorizing exceptions to it, you could just learn a rule with no exceptions.

I dont need to memorize anything, the 2 rules are inferable from how js works and you will get typescript (not even linter) flagging lines starting with those brackets anyway.

And yet, per the spec, new syntax features are allowed to break ASI:

> As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed.

So really, the rules are “there are currently 2 exceptions and an infinite number allowed to be added at any time”. To me, that’s worth letting prettier auto-insert semicolons when I hit save.

Reply on news.ycombinator.com