Open joliss opened 6 years ago
Your issue sounds like a rollup-plugin-commonjs
issue - in this case, from
is a variable name, not a keyword.
ES6 modules support added to NodeJS recently, to webpack
- not so recently, but it does not work in engines without descriptors support (IE8-), it's still not added to browserify
, etc.
So, for core-js
now makes no sense change the modular system. I think that in the future makes sense add a version of core-js
package where CommonJS will be transpiled to ES6 modules, but not soon.
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:
module.exports = {...}
can be changed to export {...}
module.exports = function () {...}
have no equivalent in esmIn esm it would be written export default function() {...}
which is equivalent to module.exports.default = function () {}
.
So I'm suggesting to use the module.exports.default = function () {...}
instead of module.exports = function () {...}
. That way switching from commonjs to esm would have no breaking change and core-js
could became a transpiled version of a core-js-es
.
@hlehmann I am thinking about something like that, but for core-js@4
.
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 @babel/polyfill
is deprecated, once again be able to reference a single file to get the abilities of the @babel/polyfill/dist/polyfill.js
build back (e.g., something like import "./node_modules/core-js/dist/core-es.js";
).
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!
@hlehmann I am thinking about something like that, but for
core-js@4
.
:+1: that's a great news!
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?