bundle size worse than preset-env with esmodules:true ?
See original GitHub issueI was looking into migrating a project that I maintain to preset-modules. However, I’ve noticed that the resulting bundle size is actually bigger than when I use preset-env with esmodules:true.
I’m not entirely sure that this is the fault of preset-modules, but I can’t seem to figure out why it’s behaving the way that it is.
To reproduce:
If you clone single-spa, checkout the 5.0 branch, yarn
install, and then run yarn build:analyze
, here’s the output (which is using preset-env with targets:{esmodules:true}
- focusing only on the esm
bundle:
./src/single-spa.js → ./lib/esm/single-spa.dev.js...
-----------------------------
Rollup File Analysis
-----------------------------
bundle size: 42.974 KB
original size: 53.199 KB
code reduction: 19.22 %
module count: 23
Then, if you yarn add -D @babel/preset-modules
, change the .babelrc
file to use @babel/preset-modules
(for the “esm” environment), and then run yarn build:analyze
again, here’s the result:
./src/single-spa.js → ./lib/esm/single-spa.dev.js...
-----------------------------
Rollup File Analysis
-----------------------------
bundle size: 45.098 KB
original size: 96.12 KB
code reduction: 53.08 %
module count: 24
If I do a comparison between the two compiled files, it appears that the size difference comes down to two things: 1)there’s an additional function added:
function _typeof(obj) {
if (typeof Symbol === "function" && typeof Symbol.iterator === "symbol") {
_typeof = function (obj) {
return typeof obj;
};
} else {
_typeof = function (obj) {
return obj && typeof Symbol === "function" && obj.constructor === Symbol && obj !== Symbol.prototype ? "symbol" : typeof obj;
};
}
return _typeof(obj);
}
and 2) all the arrow functions were compiled back to normal function
s.
I’m not sure why either of these things are happening, especially the transpilation of arrow functions to normal functions.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:7 (1 by maintainers)
Top GitHub Comments
confirmed to work while using latest babel and
"bugfixes": true
Ah, thanks, I wasn’t aware that babel behaved that way.
Thank you for looking into this.