Current coverage is 84.94%

Merging #3225 into master will decrease coverage by -0.22% as of 976edfc

@@            master   #3225   diff @@
======================================
  Files          215     215       
  Stmts        15653   15654     +1
  Branches      3353    3354     +1
  Methods          0       0       
======================================
- Hit          13331   13298    -33
- Partial        678     712    +34
  Missed        1644    1644       

Review entire Coverage Diff as of 976edfc

Powered by Codecov. Updated on successful CI builds.

This is an interesting one, it's kind of a breaking change, but also for spec compliance. How should we handle it?

@thejameskyle I think in general spec-compliance failures are bugs and correcting them should be versioned as such. People need to figure out correct syntax (e.g. by consulting the spec / articles [though those can have errors] / discussions) as opposed to having an expectation that Babel interpreting it a certain way validates it and that's a contract to continue interpreting it that way. In other words, if the syntax was broken in the first place I don't think Babel should be responsible for not "breaking" it by fixing its interpretation.

I think it's going to be problematic to have to bump the major version to do spec conformance fixes, especially if plugin and core component versions move in parallel.

And of course this syntax isn't even standardized yet so should be seen as experimental and unstable even if you do follow its "spec". Not entirely sure what versioning scheme makes sense for that.

Yeah but again this was supposed to be one of the benefits of splitting everything up into plugins, they could be versioned properly even through spec compliance chances.

@thejameskyle yeah I'm not arguing against that (from your recent comment I actually thought you came down in favor of maintaining the single version line), but what is the proper versioning (and is it different for standardized stuff vs. proposals)?

Is every spec compliance fix going to be considered a breaking change? Perhaps that actually makes more sense for proposals, but if incorrect interpretation of standardized stuff is corrected is that not a bug fix? I'm not being a troll, I just need to understand (and collectively perhaps we need to figure it out, if I'm not the only one who's uncertain).

What about #3220, is that a breaking change in Babylon? (To me it's a bug fix.)

On another note (not a spec-compliance issue), #3176 could break people's stuff if they were relying on the old behavior, but I interpreted it as a bug fix (and I think it would be insane to bump the major of everything -- babel-core etc. -- to change it).

Idk, if this were a spec compliance change in a plugin, I would favor bumping on any breaking change, but since its in the parser we'd have to bump everything (babel-core, etc), so idk. I guess this isn't that significant of a change.

Semver is very inadequate for a compiler/parser. I'd say this is fixing a bug since we weren't following the specification.

should of cc @jeffmo to be sure (obvious in hindsight)

Woo! Thanks for fixing this :)

Can use jscs to autofix if necessary. Made a simple PR jscs-dev/node-jscs#2057.

Instructions: https://gist.github.com/hzoo/cc8af2132d1775d8511d

Just stumbled accross this, why do we need to throw an error here while it is optional everywhere else? Does the spec is really that strict (should crash if no semicolon)? Shouldn't this be a linting issue?

Yeah I thought it was a linting issue initially as well - in the OP https://phabricator.babeljs.io/T6873

@mgcrea Did you check out the reference link in the OP?

Nop, but I should have! I got it.

I'll add my +1 for the "this broke our builds and took me by surprise". I do agree that a spec-compliance issue is more of a bugfix than anything else, but is there a better way to call these out in future? Maybe introducing a transition version with a loud (but non-breaking) deprecation warning?

@dylanpyle Yeah we can definitely try making it easier to transition. Sorry about that, we will add a deprecation message for future breaking changes in the parser and figure that process out..

For this particular issue, you can use my jscs branch to autofix the semicolons if that's helpful which I mentioned above #3225 (comment).

FWIW, this hit me too, and all my dependencies are pinned to exact versions. Code that was working fine locally failed in staging, I was only able to reproduce locally by blowing away my node_modules and installing fresh. I'd have been able to avoid this if i'd been using shrinkwrap. However, I should add that my mistaken use of a semicolon here from mimicking widespread examples of using class properties.

time to revert this! tc39/proposal-class-public-fields#26 (comment)

@kittens is this something you plan to take care of or should one of us submit a pull request backing this out? I'd just do it but that seems like poor etiquette.

@ziemkowski this is the bug for it (title is worded a bit strangely).

@flying-sheep

I will follow up with Babel and to get this fixed so that ASI works as expected there.

tc39/proposal-class-public-fields#26 (comment)

We'll do a PR reverting the commits shortly (I made another commit after this fixing error location)

@hzoo? Do you have an eta? End of this week?
We need to move to Babel 6 for another feature but this one is holding us back.

Not sure, I put what we want to get in https://github.com/babel/babel/milestones/6.5.x - maybe this weekend? #3332

Ok! Released https://github.com/babel/babel/releases/tag/v6.5.2

cool stuff!