16. Modules - about "module folding"

[Björn Harrtell]

Your bullet point "On the flip side, module folding, combining multiple modules into a single module becomes simpler, too." has got me wondering what you mean, because it does not seem so simple to me.

I think the most common pattern to package lots of modules is to use objects as namespaces. Examples of this pattern is Ext Js, OpenLayers etc. I also have it in my own library JSTS. In complex libraries you need more than the top level namespace.

With ES6 modules you can still export an object literal with symbols from other modules, also in multiple levels, but then you cannot selectively import symbols to get the full benefit of tree-shaking, so I assume this is not what you mean with module folding and indeed does not seem to be an idiomatic way to use ES6 modules. Or am I missing something here?

I conclude that you can only represent a flat namespace in a single ES6 module, so for a complex library you will need to keep it as a collection of several modules. Then again this goes against the rollup idea of jsnext:main that can only point to a single module bundle. Not allowing more than one module in a package seem very limiting to me.

If you ever get time to expand on this subject of module folding, I look forward to it!

/Björn

[Björn Harrtell]

Got tipped about this section in the specification which I think can explain the subject of module folding a bit - http://www.ecma-international.org/ecma-262/6.0/#sec-module-namespace-exotic-objects.

[Björn Harrtell]

From further learnings I think that the combination of import * as obj and export { obj } achieves "module folding". But it seems that doing this ruins tree-shaking, at least as implemented in rollup. I've created an issue for that at https://github.com/rollup/rollup/issues/597. Perhaps it's a given that it cannot be tree-shaken, I don't understand the implications well enough yet, but that would be sad because to me that would mean that a module bundle can only contain a single namespace.