import posts from './posts';
export default {
posts
};
This is not the ideal way to handle export in ES6.
Ideally, the export would be just:
import posts from './posts';
export {
posts
};
or even shorter:
export {posts} from './posts';
The reasoning is that in ES6, exports are not objects but bindings (references). Meteor has done a lot to wrap those so that they maintain ES6 compliant behavior, which means that by using the last version, the actual posts object gets exported from the module, complete with changes over time.
http://benjamn.github.io/empirenode-2015/#/ is a nice slideshow by meteor's own benjamn which describes all the best parts of modules from ES6 including this information.
in file https://github.com/kadirahq/mantra/blob/master/spec/3.dir-layout.md
This is not the ideal way to handle export in ES6.
Ideally, the export would be just:
or even shorter:
The reasoning is that in ES6, exports are not objects but bindings (references). Meteor has done a lot to wrap those so that they maintain ES6 compliant behavior, which means that by using the last version, the actual posts object gets exported from the module, complete with changes over time.
http://benjamn.github.io/empirenode-2015/#/ is a nice slideshow by meteor's own benjamn which describes all the best parts of modules from ES6 including this information.
http://www.2ality.com/2014/09/es6-modules-final.html#re-exporting also talks about the best ways to re-export. The entire thing is worth a read to really understand modules.