I would probably initialise those to `undefined` explicitly and use a noUninitializedClassFields linter rule. Hope that typed dialects could take advantage of the type declaration to do better ASI without requiring initialisation.
Computed properties in class bodies make the calculus a little different for @StandardJS - much harder to say "don't do that" when they're needed for symbol based protocols.
-
-
Computed propreties don't complicate the basic no-semi rules. But StandardJS *will* have to be updated to recommend ; prefix in those cases.
-
Part of the reason the ; prefix looks ok in other contexts is that it's rare and people code around having to do it. It's a little ironic that "semi-free" style turns the starting token for computed properties into ";["
-
To me this just doesn't comes up in code solving business problems. I've always looked at classes and all the additions(private / public) as library author things, which I'm not doing. The extent I use classes and class properties is literally just React.
-
I could believe that no-semi style overlaps a lot with not using classes or avoided new class features.
-
I previously used Mobx a lot where you reach for classes(decorators also) to solve a lot of problems, and this just never came up honestly.pic.twitter.com/dcQNqKp11p
-
This code is pretty :)
-
Thanks, now think of how it would be ruined with semi colons.

-
Eh. As a Ruby and JS programmer, I get used to the "look" of code in different languages. I don't necessarily mind the semicolons but I also don't mind people using tools that make no-semi style work well for them.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.