Semicolon position for "semicolons: as-needed"

[MichaReiser]

I'm about to implement the semicolons: as-needed option. I prefer to always add semicolons, which is why I'm not very familiar with the established standards when omitting semicolons. One question I ran into when implementing the option is where to put the semicolon in case it is required.

Start of statement:

Prettier puts the semicolon in front of the expression that requires the semicolon.

console.log(a)
;[1, 2]

The downside of this approach is that it may require multiple formatting passes when such an expression has a leading comment because:

Input:

console.log(a);

/* comment 1 */ /* comment 2*/
[1, 2]

The comments are leading comments of the array expression. This becomes the following code after the first pass

console.log(a)

/* comment */ /* comment 2*/
;[1, 2]

The comments have become trailing comments of the console.log(a) expression because it is between the ) and the ; of the previous statement.

The second formatting then results in

console.log(a) /* comment 2*/

/* comment */
;[1, 2]

I don't expect this to be a significant problem, but something to keep in mind.

It's also worth noting that Prettier places comments at the end of properties and not in front of the next class or type member.

class A {
  a;
  [computed]
}

// and not 

class B {
	a
	;[computed]
}

The main upside of the approach is (from Prettier's documentation)

• With a semicolon in front of that [ such issues never happen. It makes the line independent of other lines so you can move and add lines without having to think about ASI rules.

StandardJs also puts the semicolons at the beginning of the statement.

End of previous statement

My intuition would have been to keep the ; with the previous statement if it is necessary:

console.log(a);
[1, 2]

The downsides of this approach are:

• is different from what Prettier does
• Adding a statement that requires semicolon results in a two-line diff: The added semicolon at the end of the previous statement and the changed statement itself.
• it is necessary to look up the next statement to decide whether the semicolon should be kept. I anticipate that this cost should be neglectable (maybe about ~1-2% slow down)

[MichaReiser]

Related prettier issues:

• Empty line not preserved before leading ; with no-semi prettier/prettier#1510
• Missing a line break when semi at the beginning of line prettier/prettier#12211
• Semicolon before leading line comment unstable prettier/prettier#5022

[Conaclos]

I think that the case is sufficiently rare to choose either option. I could favor familiarity with prettier, composability, and ease of implementation. Thus, I voted "Start of statement".

[ysageev]

Yeah, I would do what StandardJS and Prettier do, unless it's a pain, in which case do whatever you want.

Honestly, the one or two times I encountered this issue I thought it was a bug in prettier and just rewrote my code.

Also, thank you so much for doing this. 😎

[jeysal]

Adding a statement that requires a semicolon results in a two-line diff: The added semicolon at the end of the previous statement and the changed statement itself.

This sounds a lot like adding another expression at the end of a block in Rust, and it's never bothered me.

It appears the assessment is mainly the comments complexity you describe versus Prettier conformance. It's been pointed out that this case is rare (and I agree from the few bits of no-semi code I've written in the past) so I don't think Prettier conformance weighs heavily. If the extra complexity is significant, I'd go for after-the-statement.

Another minor point: When Prettier creates something like

console.log('hi')
;['warning one', 'warning two'].forEach((warning) => console.warn(warning))

I will be so appalled that I change it to

console.log("hi")
const warnings = ["warning one", "warning two"]
warnings.forEach((warning) => console.warn(warning))

We might as well save that trouble by putting the semicolon after the console.log, which people will be more used to (and is perfectly normal in languages without ASI like Rust)

[MichaReiser]

That resonates with my perspective but I did some more research and putting the ; at the beginning of the statement is common in Prettier and StandardJS. The main reason is:

With a semicolon in front of that [ such issues never happen. It makes the line independent of other lines so you can move and add lines without having to think about ASI rules.

Which makes a lot of sense to me and e.g. is one of the main reasons why trailing commas are on by default, so that it's easier to re-order lines.

[jeysal]

Yeah I did see that on the issue and it is a good point. Of course, what I mentioned about "ugliness" can also be interpreted in the other direction — if semicolons are so ugly that some people restructure the code to avoid their necessity, it will be naturally easy to rearrange and at the same time easy to read without the disturbance of semicolons in unexpected places that take away your focus

[MichaReiser]

That's what StandardJS promotes if I understand it correctly. They even have a lint rule for it.

To be fair to prettier's approach. The issues have very few upvotes, proving that it isn't a big issue in practice and isn't worth fixing.

[jeysal]

Are there cases where it is exceptionally hard or ugly to refactor to avoid the necessity for a semicolon? Otherwise, it could be good to do beginning-of-statement semicolons and then build such a lint rule that forbids them and enable it by default if semicolons==as-needed? 😅
Would be interesting though, enabling a lint rule based on a formatter setting 🤔

[MichaReiser]

Creating such a lint rule should be possible from what I understand today. It may then be worth lifting the semicolons option from the formatter to the javascript section.

[realtimetodie]

This is a challenging viewpoint

I do not like this poll. Why would you follow the competition? Why not follow the developers? No, not by some poll, but by simply using GitHub search as a customer research tool, to find the most frequently used JavaScript standard.

[jeysal]

The most frequently used standard correlates weakly at best with the best standard, so I don't think that should be a bigger argument. Plus GitHub search is a very unreliable way to find out about all users, as it is susceptible to both overcounting and undercounting. It's very hard to get actual popularity stats for something like this.

I think the poll will not be the single basis of this decision. It is also very valuable to get the discussions about merits of each options going. If there is a strong case for one option due to big objective advantages it has over the other, the poll will likely not overrule that. That is much more important than the poll here.

[realtimetodie]

Please do not misunderstand me, it was only an idea. I am super creative. But the counterargument is a little bit to general for me.

I have not seen any scientific research on "coding standards" yet. We are talking about new research horizons. In 2022, billions of lines of code are publicly available on GitHub by millions of developers. Yes, why not quantify the most commonly used JavaScript or Java coding standard by using GitHub as a data source? Rome could get rid the "opinionated formatter" label and become the first "quantified formatter" in history.

To be honest, I like this user research idea so much, I would like to read @sebmck's opinion on this 😄

[ysageev]

I think I speak for most people when I say that whatever you choose will be acceptable, as long as 99.999% of the hideous semicolons are removed.

I would limit solicitation of feedback on this issue and move on with what you think is best, otherwise it's going to be an energy drain endlessly debating an edge-case that doesn't really matter in terms of dev experience.

[jeysal]

I agree, and I suspect this is what @MichaReiser is going to do very soon 😅
I tried to take the other position and find arguments for end-of-statement even though the prior art seems to point towards beginning-of-statement. But beginning-of-statement just has too strong of a case it seems 😅

[ematipico]

I am here just to say that I love your pragmatic approach @ysageev ! ❤️

[MichaReiser]

Thank you all for your feedback. The results are, not surprisingly, fairly balanced.

We'll go with the "start of the statement" as this is the established standard by Prettier, StandardJS, and has the advantage that you can easily move statements without worrying about ASI. This comes with the downside that we'll inherit some of the bugs that Prettier ran into too but they are rare enough, and it's easily possible to rewrite the statement to avoid the need for the semicolon in the first place.