Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

es6 module support? #134

Open
kkimdev opened this issue Apr 20, 2018 · 8 comments
Open

es6 module support? #134

kkimdev opened this issue Apr 20, 2018 · 8 comments

Comments

@kkimdev
Copy link

kkimdev commented Apr 20, 2018

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
Copy link

foo123 commented Mar 3, 2019

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 #124 provides a workaround for making UMD modules gracefully fallback, detect and load in global scope when loaded through es6 module system

@isysd-mirror
Copy link

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
Copy link

foo123 commented Apr 14, 2019

@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
Copy link

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
Copy link

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
Copy link

DexterHaxxor commented Jun 12, 2021

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

@Danielku15
Copy link

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
Copy link

robrez commented Jan 19, 2022

Related kind of - #127

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants