es6 module support?

[kkimdev]

Would it make sense for umd to support es6 module exports?

Though one practical issue is that there is no good es6 module feature detection as of now to my knowledge.

[foo123]

Also interested in this approach as it would make UMD universal again. It is easy to add for example:

if ( loaded_as_es6_module )
    export default factory();
else if ( module && module.exorts )
   module.exports = factory();
// and so on..

But the problem currently lies in detecting if loaded through es6 module system???

Although this issue https://github.com/umdjs/umd/issues/124 provides a workaround for making UMD modules gracefully fallback, detect and load in global scope when loaded through es6 module system

[isysd-mirror]

if ( loaded_as_es6_module )
    export default factory();
else if ( module && module.exorts )
   module.exports = factory();
// and so on..

This, unfortunately, won't work since export and import must be at the top level.

[foo123]

@isysd-mirror

True as the spec is right now, it wont work (plus transpilers cannot parse it correctly as far as my knowledge of current transpilers is correct).

Are there any workarounds? (Not necesarilly for transpilers, only for native spec)

[isysd-mirror]

The closest thing to a workaround I know is to use esm to publish an ES6 and Node.js compatible module.

If you want to take it a step further, and begin weaning yourself off of node_modules dependence, check out this isomorphic module boilerplate, and it's introduction.

I originally started writing this boilerplate as a PR to UMD, but I just don't see how I can add anything to the module code itself that esm didn't already write in their README.

[sokorototo]

A good solution is if export could be called as an inline function instead of explicitly as a keyword. You can use "import(module)" inline as a function but you can't use "export(module)" as an inline function ironically.

[DexterHaxxor]

function isModule() { try { return !!eval("import.meta"); } catch(e) { return false; } } How has not anyone thought of this? Maybe gonna make a PR.

[Danielku15]

I was also wondering if anyone found a real solution for this or heard about some further discussions on the design of ES6 modules? I want to support ES6 modules in my library but I don't want to double my shipped output files just to ship one with UMD and one with ES6 modules.

IMO it's quite a design flaw in the ES6 module spec to now allow a more dynamic exporting but require top level export statements. Whoever designed this seemed to have ignored that not everyone can fully rely on ES6 modules and some interop with other systems is still required.

[robrez]

Related kind of - https://github.com/umdjs/umd/issues/127