-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Plans for ES6 module support? #385
Comments
Your issue sounds like a ES6 modules support added to NodeJS recently, to So, for For better support transpiling CommonJS -> ES6 modules feel free to propose changes and add a pull request. |
@joliss Did you ever end up getting this to work? I'm fighting the same battle right now. |
@zloirock currently webpack concatenation doesn't work with core-js because it needs es6 modules. Because core-js is made by a lot of small modules, concatenation could have a big impact in bundle size and loading time. This could also be used for your bundled version of core-js. I fully understand that the priority is to ensure v3 to be ready and fully integrated, with babel for example. The transcription from commonjs to es6 modules could be done later but there is a breaking change that could be addressed today:
In esm it would be written So I'm suggesting to use the |
@hlehmann I am thinking about something like that, but for |
Besides the use case for bundlers, if core-js source can be converted into ESM, it should also be easier for your build process to use Rollup (webpack doesn't support ESM yet) to provide an ESM distribution file so that the likes of apps that don't want to bother with build steps and the resulting burden it places on the debugging feedback loop (e.g., for demos or test files)--could, now that |
Doesn't <script type="text/javascript" src="./node_modules/core-js-bundle/index.js"></script> Work for your usecase? |
I guess it would, thanks! :) |
I dream to be able to use proposals only covered by core-js@3 (thank you @zloirock by the way) like: <script src="https://unpkg.com/core-js/proposals/iterator-helpers?module" type="module"></script> But this will be a possible only if the published package contains an esm version ;) I also tried to convert core-js to es modules but ran into a lot of issues (the same as described above) and finally dropped. As of core-js-bundle, it may be usefull for quick dev, IE or old safari; but it's way too heavy (~50kb minified) for this!
👍 that's a great news! |
All this back and forth is due to core-js not supporting ESM yet: zloirock/core-js#385
All this back and forth is due to core-js not supporting ESM yet: zloirock/core-js#385
So I'm a big fan of ES6 modules, because they have statically analyzable
import
/export
syntax with well-defined semantics, which means that bundling doesn't need to rely on any sorts of heuristics.Babel's transform-runtime plugin has the ability to emit either
require
orimport
statements when it pulls in core-js modules. I was trying to get this to work withimport
statements and Rollup, so that our app would only include the parts of core-js that it needs, rather than the whole library.But since core-js uses CommonJS internally, it seems to be necessary to convert it to ES6 modules with rollup-plugin-commonjs before feeding it into the Rollup pipeline. I haven't been able to get this to work at all, which is probably due to the limitations of using heuristics to parse
require
calls.I'll provide below a sampling of error message that I ran into as I tried to get it working. I don't expect these will be useful to track down any particular issue, but perhaps they'll illustrate the difficulty of getting
require
-based bundling to work.So I'm wondering if there are any plans to have first-class ES6 module support in core-js?
With an older version of Rollup:
Yet another configuration compiles but with a lot of warnings ...
... and throws a runtime error:
The text was updated successfully, but these errors were encountered: