meteor-babel

meteor-babel copied to clipboard

I'm a little surprised that this package is marked as "deprecated". For me, the new "babel-compiler" is not a complete replacement, as it runs only on the server. So when trying this for my client-side code, meteor threw an error. I really try to get convinced of the Meteor ecosystem, but too often I encounter problems like these because Meteor has it's very special way of dealing with things. And if a third party package is being dropped without a complete substitution in the standard, this does not help very much...

The ecmascript package (coming in Meteor 1.2) will process both server-side and client-side code using Babel.compile, though Babel.compile runs only on the server. Actually compiling code on the client is not required for running compiled code on the client.

Also, the grigio:babel package will continue to work alongside the ecmascript, though I totally understand if the maintainer prefers to deprecate the project so he can focus on other work!

Exacly as @benjamn said grigio:babel born to support ES2015 but the open known issues need to be fixed elsewhere.

So @grigio @benjamn, what package should one use for front-end es6 going forward? Should we just hold out for Meteor 1.2?

meteor add ecmascript or https://github.com/jedwards1211/meteor-webpack-react

Some features provided by grigio:babel might be not available in other integrations but some > ES2015 feature provided by the polyfill are very risky, example https://github.com/numtel/pg-live-select/issues/3

UPDATE I've also wrote a post why I think grigio:babel and all the other NPM wrapped packages are wrong, specially if you are going to use ReactJS or AngularJS with Meteor

@benjamn but ecmascript doesn't support await/async, even generators.

@f0rmat1k is that true? What "stage" of babel is that package using? seems like it should be configurable or just go stage-0 (in babel 6 it would need to include the right plugins / presets)

Here's the current list of supported Babel features: https://github.com/meteor/meteor/blob/devel/packages/ecmascript/README.md

Notable features missing from the Meteor 1.2 ecmascript package:

• modules (need a CommonJS module system first, which is one of the big new features planned for Meteor 1.3)
• async functions and generators (could have been in 1.2, but somewhat easier to implement once we have a module system)
• decorators (spec far from final; will reconsider after the next TC39 meeting)

If you need any of those features, then you should either fork the ecmascript package and try enabling your desired stage 0 features (though we can't help you if they don't work yet), or keep using grigio:babel, and not consider this package deprecated until Meteor 1.3.

The ecmascript package will upgrade to Babel 6 once it's stable.

@benjamn what is the problem with stage-0 in meteor?

@jeffshaver It's important for us, as a framework that serves lots of different kinds of developers, not to lure our developers into writing code that could easily cease to work when the spec changes. From that perspective, it would be disingenuous for the ecmascript package to appear configurable at the level of individual Babel features, because that would encourage folks to try arbitrary combinations of features, even though not all combinations of features will actually work (well or at all).

Now, it's great that you've self-selected as a stage 0 enthusiast. In fact, we'd love to hear about your experiences with stage 0 features. We just ask, for our own sanity, that you enable them through a package (like grigio:babel or your own fork of ecmascript) that isn't the one installed by default in all new meteor apps.

If you stick to features that have a good chance of becoming part of the language, then we promise they will be supported as soon as possible, after they've advanced to stage 2 (or maybe sometimes stage 1).

@benjamn I guess I don't see what the problem is. If you use stage-0 than you know the risks associated (or should at least). If you have it set to stage-0 but use none of the stage-0 features than it is just like having it set at stage-2. I understand that meteor serves a lot of devs, but it seems like it has little downside. By enabling stage-0, you aren't recommending its usage, you are allowing it. You could even point out in the ecmascript package docs/readme that meteor doesn't personally recommend it.

It more-so seemed as if you were saying certain babel transforms wouldn't work in meteor due to changes that would have to happen to meteor itself.

By enabling stage-0, you aren't recommending its usage, you are allowing it.

That distinction may seem clear to you and me, but it's hard to enforce a distinction like that with words in a README, so it ends up being a blurry distinction in practice. If Babel ever removed a feature because it was withdrawn from the standards process, that decision would pose a backwards compatibility risk for Meteor, and we would have to think seriously about how to help people who decided to use it migrate their code away from that feature.

It more-so seemed as if you were saying certain babel transforms wouldn't work in meteor due to changes that would have to happen to meteor itself.

That's definitely true in the case of ES2015 modules, until the necessary changes have been made.

@benjamn I guess that makes sense when thinking about enabling stage-0 by default. But why hold back users who want to use stage-0?