Can we do without the .import extension?

[mhagmajer]

There is a native support for ES2015 in Meteor since version 1.2? Can we therefore update this package to not depend on different file extension? I need that to make it work properly with Flow type checker (http://flowtype.org/). Thanks!

[MacRusher]

Unfortunately not. There is some support for ES2015 in Meteor since 1.2, but it lacks modules. You'll have an error if you try import or similar statement.

So we must use our own build plugin, which is actually pretty similar to what ecmascript package is doing, but also adds modules support. And for that we need custom file extension. I think that flow plugin is also enabled in our builds (because we extend Meteor default babel config). What exactly problems you got with it?

[mquandalle]

Since Meteor 1.2, built-plugins packages can register .js extensions so we could have .js files with modules by adding universe:modules, removing ecmascript and defining an entry file for both the client and the server — which is what https://github.com/thereactivestack/meteor-webpack does for instance.

[cristo-rabani]

Hello,

I consider that it could be done for all files, but from another side import.js(x) have some benefits (there are not conflicted with other packages.

Maybe some other way: I think that we can make a second package e.g.: universe:modules-in-all-js And this package will be inherit from universe:modules and it will provide support of modules in all js(x) files.

[MacRusher]

I think that this could be done as opt-in option, without need for an extra package. Doing this as a default IMHO could be confusing and error-prone.

I'll also have to check how will this behave when there will be both ecmascript and universe:modules in this mode installed side by side, or by mistake e.g. when some package will imply ecmascript.

But definitely this is something worth considering.

[mquandalle]

It won’t work if the application includes both ecmascript and a package that want to register .js, for instance:

=> Errors prevented startup:                  

   While determining active plugins:
   error: conflict: two packages included in the app (webpack:webpack and ecmascript) are both trying to handle *.js

I think Meteor handle just fine the case of a package that need ecmascript to compile and another one that need something else. I guess you’ll have an error if a package imply ecmascript but I can’t see any reason to “imply” a compiler (which is only used to compile the package files).

[MacRusher]

Yeah I thought that this will happen. But you're right, no package should imply ecmascript so we should be good here.

I still think that this should be an opt-in and a conscious decision, do you agree with me?

@cristo-rabani is right, we could prepare a package that will enable this so standard universe:modules can still work with ecmascript. Or maybe you got some idea how to configure Plugin.registerCompiler based on a way that will be easy to use and understand by developers?

[rozzzly]

+1 Please play around with this. I've been wanting to add this to one of my projects for a while, but have been holding off because

• MDG says meteor will eventually support es6 modules
• I refuse to rename every file in my project with .import.js. In reality, it's just a filename. My stubbornness isn't logical, but it just feels wrong.

Following the pattern from https://github.com/thereactivestack/meteor-webpack, this should work quite easily as I understand it. So, then it would be the inverse of what this package does now? not really, but the way the importable files are filtered would be!

I propose that *.entypoint.js be filtered out and handled as a js file would normally in be in meteor, then have everything else be the targeted by the custom compiler.

A single main.entrypoint.js looks sooo much better than all of those *.import.js files imho.

[cristo-rabani]

I think that "main.js" or "index.js" in root of app can by the entry point.

[rozzzly]

What about multiple entry points? I'm sure there are many other cases in which that might not work the best. Either would work, but I believe an arbitrary filename could be unnecessarily restrictive.

Oh and by having whatever.entrypoint.js, it is explicit that the file is being handled differently whereas just a main.js or index.js would be more susceptible to confusion.

[cristo-rabani]

We already use index.import.js in package as a root file of package. The main.js as a filename has benefit, Meteor will load it at the end (in moment when we have all deps registered) I worry about situation when entry point will be launched before all stuff will be registered

[cristo-rabani]

P.s. This can be configurable or all files main.js in all directories might be treated as a local entry point.

From the other site. I cannot imagine of situation when one main.js is insufficient. Because if we need more that main.js can be entries router. (In my opinion, Many entries in the same way as globals is often responsible for the mess in project)

[MacRusher]

Ok we discussed this internally and decided that we will introduce new package: universe:modules-entrypoint (if you have better name we're open for suggestions :))

It will load our build plugin on all .js files (just like we do now on .import.js). App will start with loading main.js file in root directory that will be only entry point.

@mhagmajer @mquandalle @rozzzly does this solution satisfy you?

[mquandalle]

Yes.

On the packages organization I recommend having a base package (universe:modules-compiler) that doesn’t register any build plugin but only export a configurable universalMobulesCompiler (and also add the polyfills to the bundle). Then you can api.use this compiler with the correct options in the two specifics packages that register a build plugin (universal:modules and universal:modules-entrypoint). This is similar to what I have done with meteor-jade and it worked pretty well (another positive consequence is that it allows developers to create new build plugins that require and extends your base compiler package). I also recommend keeping the 3 packages in the same GitHub repository like does collectionfs or jade.

[MacRusher]

Hey guys, please check out package universe:modules-entrypoint: https://github.com/vazco/meteor-universe-modules-entrypoint

This is a drop in replacement for universe:modules that uses .js(x) instead of .import.js(x) extension.

There could be some corner cases I haven't checked so it would be great if you give it a shot and tell me how it goes!

[radekmie]

We've decided to archive some of our repositories as we are no longer using nor willing to maintain them. Part of this process involves closing related issues and PRs. If you still need help, do contact us on opensource@vazco.eu.