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.
@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.
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.
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:
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.