Babel v6.4 Requires semicolons after class properties

[cableray]

See babel/babel#3225. Seems like this is an incompatible change with standard. Anyone aware of this?

[dcousens]

If the JS specification defines that a semicolon must be after a class property, then, well, we'll have to adapt to allow that rule.
If it doesn't, then I suspect its just a matter of time until Babel can adapt or we'll have to make an exception.

@kittens? 🎱 Haha

[bcomnes]

Urg, gross. So ASI won't work inside of classes?

[LinusU]

I think that babel was a bit quick to jump the gun here, but on the other hand they are targeting an unfinished spec so I guess that that is expected.

@feross I think that your name has some weight in the javascript community and I would love for you to chime in with your thoughts over at tc39/proposal-class-public-fields#26

I think that they have a very bad rationale for requiring the semicolons, and I still think that there is time to change their minds about this. It seems very strange to require semicolons in this particular place, when they aren't needed elsewhere.

[flying-sheep]

i think it’s simply a quick&dirty rule to have something backwards-compatible. (you can always remove a semicolon made redundant by ASI, this way introducing ASI will never generate a syntax error)

well, unless the definition gets changed to be similar to method literals which may not have semicolons (AFAIK)

i think medium-to-long term there will be intuitive elision rules for class properties, we just have to keep vigilant so that this doesn’t accidentally end up in some standards document

[ThaJay]

It just cost me way too much time to figure out what had changed after trying to deploy my app on our server.
pretty lame we have to find out through a git isse. it's really hard to find this way. A blog post would have been nice, as I'm sure I am not the only one who has a problem with this (even if this change complies to the standard in it's current state).

It would have been logical to include configuration to make this behavior optional, there is nothing breaking about not wanting to comply to this detail.

It's actually flagging all my arrow functions that contain 'this', so now I have to refactor those back to normal functions and manually bind 'this'.

[cableray]

@ThaJay It was also in the release notes, but kind of hidden in there.

[GantMan]

btw. I just merged a 56 file update in our "Standard JS badged" project. Where 56 semicolons were added. I can't imagine many people are happy with this.

[thejmazz]

ugh, now won't all my babel ^6.x.x projects break when I clone and npm install them? I guess this what you get for playing with stage 1 syntax..

[torifat]

You can use this codemod to upgrade your code.

https://gist.github.com/torifat/83da48336867e128f2ca

export default function(file, api) {
    const j = api.jscodeshift;
    const { expression, statement, statements } = j.template;

    return j(file.source)
        .find(j.ClassProperty)
        .replaceWith(p => {
          p.node.end++;
          return p.node;
        })
        .toSource();
};

$ jscodeshift -t ../codemod/static-property-semicolon.js src/

[GantMan]

We've found that if you add proptypes from outside the class, it won't require a semicolon.

e.g.

class Showing extends Scene {
...
} // close class

Showing.propTypes = {
  hands:  React.PropTypes.jazz
}
// No semicolons!

BONUS NOTE - My coloration was off for everything that followed proptypes (ES6 color in Sublime) and now that it can't have anything follow it, because it's not inside the class, the coloration issue is fixed, too.

[rstacruz]

ugh, now won't all my babel ^6.x.x projects break when I clone and npm install them? I guess this what you get for playing with stage 1 syntax..

I recommend using --save-exact next time. I've been doing that for all my projects, and greenkeeper.io makes it easy to keep up.

[LinusU]

@rstacruz Isn't it better to use npm shrinkwrap?

[CookPete]

What I've done for the time being is use a partial shrinkwrap to pin babel-core, babel-cli and babylon to 6.3.x, which temporarily solves the issue: CookPete/react-player@630072c. It's not ideal but it prevents the build error for now.

It sounds like eventually we will have to succumb to the semicolon, if it is part of the official proposal.

[jprichardson]

It sounds like eventually we will have to succumb to the semicolon, if it is part of the official proposal.

Can anyone point out where it's part of the official proposal?

[LinusU]

@jprichardson I haven't seen it explicitly in the actual spec, but the author clarified that semicolons was indeed mandatory in this issue: tc39/proposal-class-public-fields#25. There is also a follow up discussion here: tc39/proposal-class-public-fields#26

@rstacruz Actually, that wouldn't have helped at all since the breaking change is in babylon which is a dependency of babel. npm shrinkwrap would have worked though...

[bcomnes]

It sounds like there may have been a misunderstanding with the requirement on babel's end (eg the semicolin requirement is still fulfilled by ASI and this babel behavior is a bug, except where it doesn't already with certain literals)... but still waiting for official word.

[dcousens]

@LinusU he actually goes on to say tc39/proposal-class-public-fields#25 (comment):

Yea, I think you might be right @jmm. I went in with this restriction with the mindset of creating an all-cases-work grammar, but I suppose if we don't require semicolons then only some cases don't work (and an optional semicolon becomes required only in those cases).
I will follow up here next week and plan to give an update on this at the coming TC39 meeting at the end of January.

That is, a return to the status quo of allowing ASI is still possible, but obviously up for discussion.

[niftylettuce]

@torifat thanks for this #372 (comment)

[favorit]

@torifat thanks!

[monfera]

Suddenly mandating the semicolons without a quick 'whoa, hang on a sec' option is throwing some obstacles. It was a surprise after npm install as I need to deploy code under time constraint, i.e. no time for MSI, and even fixing 6.3 in my package.json didn't help, because of the way babel modules install other babel modules underneath themselves, which have loose package specs (e.g. babel-core@6.3.26 will happily pull babel-generator@6.4.3 underneath itself).

Some kind of hotfix (error throw disable instruction or how to globally freeze at 6.3) would be helpful. I can look into it but if somebody knows off hand, I'm interested.

Fwiw it's complaining in JSX render() in my .js files which e.g. end with a but I don't know if it would happen with non-JSX stuff. My guess is that JSX gets transpiled to JS first though.

[CookPete]

even fixing 6.3 in my package.json didn't help, because of the way babel modules install other babel modules underneath themselves, which have loose package specs (e.g. babel-core@6.3.26 will happily pull babel-generator@6.4.3 underneath itself).

@monfera see my comment at theogravity/react-styleguide-generator-alt#9 (comment) with a suggested fix. In short, I used a partial shrinkwrap to pin babylon and it's dependents to 6.3.x, ie CookPete/react-player@e9bcd72

[monfera]

@CookPete Thanks a lot Pete! I've reached a similar effect after seeing a terse fix suggestion, these were my steps: babel/babel#3225 (comment)

[GantMan]

@monfera - also see my note, that moving the code can make it semicolon free. Rather than managing each person's babel, I've just changed our standard.

[monfera]

@GantMan Nice! I'm not a semicolon-hater, just wanted to avoid changing the code base b/c of this. Babel might become more compliant but I think it's at least a big oversight in the spec if semicolons are required in the classes, because before that, we had (for better or worse) clarity about ASI and optionality, while now it feels really incoherent, mandating it sometimes, even in the absence of ambiguity. I guess it's an accidental oversight or someone who doesn't like Standard Style snuck it in :-)

[monfera]

@GantMan ... just noticing this is the Standard Style board, so in that case I'm compelled to say that not using semicolons in ES2015 code is even more coherent (visually and denotationally, c.f. fat arrows, destructuring bind...) than with ES5. These and lots of other ES2015 changes (import/export, argument spread...) move JS toward less noise, so semicolons look really out of place, especially if someone favors functional composition, avoiding lots of broilerplate or other DRY violation.

[flying-sheep]

@GantMan unfortunately going back to class field assignment after the class declaration isn’t declarative.

i’d like to stick to my coding style and gain delarativeness instead of deciding between one or the other.

i hope people quickly return to ASI as outlined in tc39/proposal-class-public-fields#26 (comment)

[flying-sheep]

fyi: that’ll be reverted: tc39/proposal-class-public-fields#26 (comment)

[feross]

Looks like I missed most of this discussion. Excellent to hear that the change will be reverted, @flying-sheep. Crisis averted.

[nabn]

With babel 6, it looks like you don't need semi colons in class functions anymore. I updated standardjs, but it still gives me a warning.
What's the update on this?

[aakashsigdel]

+1 for support for arrow functions inside class as now babel compiles without the semicolon

[vslio]

I would also love to see support for this.

handleSearchBoxChange = (search) => {
  this.props.dispatch(FollowingActions.getFollowingSearch(search))
}

Using the above arrow function inside a class yields the following error...:
Parsing error: Unexpected token = (null)

... and the rest of the file doesn't get checked at all, even though there are style issues I purposely introduced. The moment I comment out the arrow function, the errors are highlighted immediately on the editor.

[jprichardson]

@vslio https://github.com/feross/standard#can-i-use-a-custom-js-parser-for-bleeding-edge-es6-or-es7-support

[vslio]

@jprichardson well, that was embarrassing... 😭
Thanks a lot for the quick reply–works like a charm! 👍