the grigio:babel package is now deprecrated, and i read that ecmasript is now part of meteor core. But i’m having trouble getting any es6 code to compile.
I see there’s an ecmascript module from MDG this package is pre-installed for all new apps and packages but it doesn’t seem to accept basic es6 syntax even if i rename files to .es6
should i just wait until 1.2 or is there a suggested way to get up and going?
It’s not quite there yet. The new ecmascript package will work in 1.2. Keep using grigio:babel until then.
thanks for the update!
do you know if there’s a way to turn babel off for certain packages?
it seems to be causing some mayhem deep within the package manager for external node modules:
I’m not sure. By default, Babel will transpile files ending in .jsx, .es6, and .es6.js. Regular .js files should be untouched.
You can also add just the jsx package and rename your files to .jsx to use the ES6 syntax. This will provide the best compatibility with the upcoming ecmascript package. I think the other package lets you use experimental features by default and you may have to change code if using that (like decorators or stage 0 things).
Editors have plugins to enable JS syntax/highlighting on JSX files. Also, you don’t have to add any JSX markup in the file.
thanks! that’s what i ended up doing (links on GH issue above). was a bit confused why they have to be .jsx but understand now
Will ES6 changes the way we develop and structure our apps in Meteor ?
For example, will it be preferable to use more object oriented style architecture to define our collections/schema (Models) and data access objects (DAO) ? I’m curious if ES6 will make javascript web apps more structured or not.
I raised the same question about grigio:babel as an issue on Github. There I was told that they deprecated the package in anticipation of the upcoming ES6 support in Meteor. I personally think that it’s not a very good idea to deprecate a package before a standard solution is already available, but I respect their choice of doing so. Yet, as a developer, this gives me a kind of “uncertain feeling”, a bit like if they were stating: “We’ve put our hands in our laps now and will not take care for this package anymore.” Nothing you would like to hear if you’re using the package in productive environment 
However, I appreciate their open source work, so this may be some kind of nitpicking from my side. At least for me, working with .es6.js files works fine so far, I’m using them in packages only to control the usage of ES6 on a per-package level. This is just because I don’t know how the final ES6 solution of Meteor’s will look like, hence I’m only using ES6 for defining my model classes for now (since I like the new class syntax of ES6 and - even better - ES7).
@skini26: I would really appreciate MDG transforming Meteor into a ES6-flavoured programming style. I’ve you should have some time, I recommend having a look at the Aurelia framework (formerly Durandal). The guy there adopted ES7 at it’s best, and the framework benefits a lot from that. In fact, it was a totally new JavaScript programming experience for me. Before I tried out Meteor, I thought about using Aurelia, but it was too slow yet, and Meteor had this “all-in-one” approach that got me. Yet, from a conceptional point of view, I still think Aurelia is the most evolved form of all JS frameworks I’ve seen so far. It would be awesome if Meteor adopted some of the ideas developed there.