I just converted my meteor-react-example app to using this. It seems to work, but it’s all a bit rushed…
Does this seem like a sensible approach? README attempts to describe the approach.
2 Likes
Really nice example app! I like the approach you described.
Can I link to you app as an another example in modules docs?
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.
1 Like
Great info guys, much appreciated! I’ll look more into module loaders in general.
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.
1 Like
I’ve merged the branch. Feel free to point to master in the example reference now.
Just a quick note:
I’ve released version 0.4 today with some fixes and support for newly introduced package import syntax from 1.2 build plugin.
We will still need Webpack/Browserify/etc because ES6 Modules don’t cover certain use cases that Browserify and Webpack do. For example, ES6 Modules doen’t handle NPM dependencies. We’ll need tools like Webpack for code-splitting to minimize duplicate dependencies in projects, etc. There’s tons of stuff for Webpack and Browserify to still do. ES6 Modules are just a simple way to start using static JavaScript, but that doesn’t include any sort of dependency handling or compiling.
Also, ES6 modules don’t allow for manual control of dynamic/asynchronous module loading. For that you’ll need the System API to control asynchronous module loading. For module naming, you’ll need to use System.register, etc, etc, so there will still be lots of work for Webpack, Browserify, and other bundlers to do.
With the current universe:modules solution, the Meteor build tool still does all the bundling work. So the result on the client is still one concatenated minified JavaScript file, where all the ES2015 modules are wrapped in System.register constructs. This approach gives still the benefit that we can use ES2015 modules syntax to declare file dependencies.
This does not handle features like lazy loading of file bundles or using NPM packages on the client.
Loading packages from external repositories like NPM is IMHO not the responsibility for ES2015 modules.
But we could add support for jspm (as an another package) that is itself based on SystemJS and allow to use npm packages or even get code directly from github 
Could you be kind enough to extend the demo to show how different packages can expose their ‘namespaces’ and interact with each other using this method? I have been looking at it for the last 2 days and my biggest hurdle is how to stop thinking in ‘package only’ and mix the two. Thanks for this very useful package.
A suggestion would be something like a notification package which can be used to show growl notifications on the page on or anything of the sort. I simply need to see a use case scenario and should be able to pick it from there.
1 Like
I will try to extend the demo as you ask somewhere around Tuesday/Wednesday next week, I hope that you can wait till then. Sorry for the delay, I’m just really busy lately.
1 Like
That’s fine. Looking forward to that. Appreciate all the hard work that has gone into this.
My main source of brain freeze is how to have a ‘namespace’ import in a different module. That way I can slowly build my apps by separating components/modules and finding a way to have all of them work in harmony.
A word on ‘clean namespace’ would help. I understand the namespace as we know them won’t exist and we are moving to pure modules. Now, if I am importing different modules in different segments of my page, how functional is that or by using ‘let’ we ensure that the global is kept clean?
I think you can start by declaring dependencies on top of each file like this:
const MyDependency = MyNamespace.MyDependency;
Then as you migrate MyDependency to use ES2015 module exports, you can just replace this line with:
import MyDependency from './path/to/MyDependency';
With System.map you can also define an alias if relative paths are a problem.
A word on ‘clean namespace’ would help. I understand the namespace as we know them won’t exist and we are moving to pure modules. Now, if I am importing different modules in different segments of my page, how functional is that or by using ‘let’ we ensure that the global is kept clean?
In Meteor the code of each file is wrapped in an immediately-invoked function expression. This means that variables that you define with var, const or let are not global.
1 Like
I just cloned this repo and added a line to check if ES6 syntax was supported
console.log(`In JavaScript '\n' is a line-feed.`)
//-> `Unexpected token ILLEGAL`
or
var [a, , b] = [1,2,3]; //-> Unexpected token [
is there something else that needs to be done to enable ES6 syntax?
Use the import.js file extension.
If it helps, it looks like the final ES2015 spec does explicitly allow implementations to implement mapping (though it doesn’t dictate specifics, so the responsibility would indeed fall on the loader implementation as @Sanjo suggested):
“Multiple different referencingModule, specifier pairs may map to the same Module Record instance. The actual mapping semantic is implementation defined but typically a normalization process is applied to specifier as part of the mapping process …”
(from http://www.ecma-international.org/ecma-262/6.0/#sec-hostresolveimportedmodule)
1 Like
Any chance you can share something this week?
So, where were their heads and what were they thinking or smoking 
if 1.2 is without ES6 modules support ;?)
They must have taken kickbacks from Misko!
1 Like
Thank you, you wonderful person
Does it decrease build times?