I don't think this is the point of the article.

Prettier is really good. But it makes not much of a difference regarding the ASI issues the article talks about, unless you (like the article describes) look at the formatting output diff everytime, and/or have tests and lint rules preventing mistakes.

Regarding ASI, if you are accidentally writing

  return
    ((oopsItsUndefinedBut ? itsSoLongThat : accidentallyIPutItOnItsOwnLine(but, that, shouldntHappenRight ?? false)

  return;
  oopsItsUndefinedBut ? itsSoLongThat : accidentallyIPutItOnItsOwnLine(but, that, shouldntHappenRight ?? false);

But the point of the article is that stylistic concerns (the change Prettier makes) do NOT solve this problem.

You need the aforementioned static typing with return annotations, lint rules, tests, anything.

And sure, JS could make it a runtime error to have statically unreachable code, like Java does (well, it can't, don't break the web etc).

Until then, ASI is an example for the author's point.

And even if this point didn't exist at all: the post is not about formatting or lint rules.

It's about the impedance mismatch between style guides / "rules of thumb", and semantic errors in program behavior.

It's about the fact that style guide can never make hard-to-spot bugs impossible.

This point is explained with examples, of which one ASI is.

There's a reason it doesn't mention static typing I guess: not even the strongest types will guard you from yourself.

So yes, Prettier is awesome, but no, it doesn't nearly "solve" the issues that the article talks about.

It's more like a refutation to the line of thinking that style guides can make all errors obvious. For example, a bit like what Joel Spolsky represented in his ancient post "Making wrong code look wrong" (although that one is not just about code style, more about naming, sanitization, hungarian notation, yada yada)