http://www.angular-meteor.com/tutorials/socially/angular2/bootstrapping 
@trajano @juliancwirko the support is not mature and the learning sources are also not mature like socially tutorial. I am waiting for some expert who will write a good tutorial on these technologies.
YES! Please! Excellent idea!!! This x100
For quite awhile I’ve been of the opinion that if MDG wants a smooth migration from Atmosphere to NPM, it would be really great to have a ‘Convert to NPM’ button on Atmosphere for package owners. With 10,000+ packages, some sort of automation is going to be needed to help streamline the process. And repurposing isobuild to build npm packages would enable that feature, and a whole bunch more.
Very supportive of this idea.
4 Likes
how’s es7 support in 1.4?
3 Likes
Fantastic!!!
I fall in love with meteor currently.
2 Likes
Please add @decorators support!
1 Like
I’m using 1.3.3-beta.1 with babelrc support. You can add decorators no problem.
3 Likes
Statics and Arrow functions in classes appear to not be supported. WTB!
Everything that is available in babel is supported… just add it to a babelrc as stated a few times already. I’m using static and arrow functions in classes just fine.
Mongo 3.2 is long available, I’m running it without problems for months. Only difference is that it becomes the standard version for everyone. If you run it on WT, the space implications are tremendous. Have seen that it takes only 1:25th of the previous space, as older Mongo keeps the file size per collection at it’s maximum size, even when you delete all docs in it.
It’s also faster but that’s not so apparent as the space saving
That isn’t quite accurate. Even though some apps can run on 3.2, there are some features in 3.2 that are broken if you try to use them with Meteor 1.3 because the node driver that Meteor 1.3 uses is not compatible with 3.2. It is compatible with 3.0 though, which also can utilize Wild Tiger. I would suggest others that are deploying a new app should use 3.0 until Meteor upgrades the node driver (which is exactly what they are working on).
1 Like
I can only speak from my own experience and it’s running fine. No problems and I’m not sure what features you mention that don’t work, maybe I don’t use them yet.
If you need decorators today can you add the barbatus/typescript atmosphere package. Then you can change the filename js->ts or jsx->tsx for the file you want to use decorators in.
In the tsconfig.json, remember to set
"experimentalDecorators": true, to enable the feat.
“allowJs”: true, so you don’t have to convert your entire app in one go.
2 Likes
Impressive work MDG! Shortening release schedule by 50% compared to previous 2. What’s changed?
5 Likes
Will there be proper usage of exports in future versions of Meteor? Ideally it would be great to utilize exports over globals.
How is that different from what meteor 1.3 does? It completely supports exports.
1 Like
Didn’t realize that, but why are there globals being used with Mongo and on the server side?
We are in the state now of being able to choose either world for most things by placing our code under an “imports” directory or not, but yes the Meteor pseudo-globals are a special case. The explanation you seek is in the guide’s Application Structure article.
Many React libraries are aggregating components via index.js using the following style:
export ComponentOne from './component-one'
However I found that the syntax of the above ES7 export style is not supported in the latest Meteor. It seems that the babel transpiler of the latest Meteor is quite up to date. Am I missing anything?
It’s supported, but that syntax is incorrect, it should be:
export { ComponentOne } from './component-one'
Yes, I know the syntax with {}
But …
Why they can use the ‘incorrect’ syntax here: https://github.com/react-bootstrap/react-bootstrap/blob/master/src/index.js
Also same used by Material UI: https://github.com/callemall/material-ui/blob/master/src/index.js
More info: https://github.com/leebyron/ecmascript-more-export-from
I was scratching my head 