-
Notifications
You must be signed in to change notification settings - Fork 422
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
Comments
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 |
This, unfortunately, won't work since export and import must be at the top level. |
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) |
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 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. |
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. |
|
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. |
Related kind of - #127 |
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.
The text was updated successfully, but these errors were encountered: