Meteor 1.2 release will lack ES6 modules support, but if you want you can use them even today!
Just add universe:modules to your project.
This package will add new file extensions: *.import.js and *.import.jsx.
These files will be bundled with your Meteor app, but won’t get executed until you request them.
This is somewhat similar to *.import.less files, that you can include inside normal *.less files.
This demo also uses react, universe:react-bootstrap, meteorhacks:flow-router and kadira:react-layout so it could also be an example on working with React in general.
What do you think about this? I would greatly appreciate your feedback!
Yes, Meteor 1.2 will have some ES2015 support, but unfortunately it will lack modules, which is one of many new JavaScript features. It’s on the roadmap, but not in the near future.
This packages actually uses official babel compiler that will be used in 1.2 (it’s already released) so you won’t need packages like grigio:babel any more, it will be build into the core.
universe:modules adds missing modules support and gives you a way to work with them.
@macrusher This is great! Modules is personally my favorite feature of ES6, and potentially game-changing. Once everyone adopts them, we can do away with the whole AMD, CommonJS, browserify, webpack, blah, blah, blah mess.
Wow, I’ve never been able to follow a Meteor app’s structure as clearly as I have when going through your repo.
I feel like I’ve just seen the future.
I really like how I can look at the top of the page and see at a glance what parts you are bringing in and from where. I also like how React has been integrated so cleanly and perfectly.
But I Have one question:
How feasible is it for me to use Coffeescript with something like this?
I think that the hardest part is to get working Babel and coffee together. Is coffeescript capable of using es6 module syntax? (quick goggling doesn’t give me an answer) If so we can add additional buildstep and have *.import.coffee files. Contributions are welcomed!
And thank you all for kind words! If you have some thoughts on modules workflow I’m open for ideas.
At the risk of sounding ignorant… will the ‘real’ ES6 modules have a way to map an import name like SystemJS does? I haven’t been keeping up with the spec lately.
The docs don’t quite make it clear that imports are always relative to the root of the app. I got confused at first because I had my main.js and routing.import.jsx equivalents in client/ and you then actually need to do:
System.import('client/routing');
And similarly in e.g. client/components/foobar.jsx:
import Loading from 'client/components/loading';
One question though: the example app only shows client-side usage. Can it be used for server-side code? In particular, is it possible to put shared code like Collection definitions in an .import.js and use from both client and server?
ES6 module spec doesn’t allow mapping, or at least I’m not aware of it.
You have a valid point here, if you want your code to be 100% future-proof then you should not rely on mappings.
SystemJS gives you this possibility anyway, so I could only not endorse it in the docs.
But this gives you some much power and comfort that ignoring it will be a mistake.
But I think that some kind of name resolution system will emerge, and MDG is planning something like this for Meteor:
ES15 modules. We will replace Meteor’s homegrown, pre-ES15 namespacing system with shiny, modern ES15 modules. We’re going to try to do this in a way that preserves Rails-style “do what I mean” automatic symbol resolution for developers that want it, while also allowing strict, explicit control of namespacing in situations where that is preferable.
So in my opinion it’s safe to use it, and we will provide some migration path when Meteor ships with modules build-in.
It’s in the docs, but I agree that this should be made more clearly. I will improve the docs based on received feedback, so thanks for mentioning this
You can actually use relative paths but only inside .import.js files. System.import require absolute path because there is no way to determine calling location when project is bundled, or at least I’m not aware of it.
All components and routes in the demo are shared between client and server. You should be able to add Server Side Rendering just by adding Flow Router SSR package that Arunoda is working on, but I haven’t tested it yet.
About collections, I have some problems with putting them inside module, I will work more on it this week.
But the definitions like simple schemes etc. can be inside a module and could used in both client and server.
I think when you put ./ in front of the path, it is relative. E.g.: import Loading from './components/loading';
Regarding the module loader: My understandment of it is that there can and will be many module loaders. One of them is SystemJS. Each browser will eventually ship with one I guess. So mapping is just a feature of a specific module loader. And you can choose which module loader to use. So SystemJS will stay I think.
Please. Right now the ES6 module stuff is on a branch. I may merge it once I’ve trialled the approach in a “real-world” app, so then it’s easier to point at master.
I’m also working on similar solution: 