Not reduce bundle size as expected

[alireza-mh]

There is a project that has been written in Typescript.
bundle size with babel/preset-env is 101.29KB minified & gzipped also bundle size with babel/preset-modules is 100.27 KB minified & gzipped.
here is a repository that you can check:
sample-react-redux-typescript
I removed polyfills for a better comparison of bundle size.
you can run yarn analysis for viewing bundle size.
node version: v12.12.0

[peter-mouland]

it depends on the output of the original bundle, but for me it will. here are some of my own test changes (with loose=true):

Rest

• webpack output length from 5696 to 4467
• rollup output length from 258 to 187
  

Template Strings

• webpack output length from 4380 to 4375
• rollup output length from 100 to 95
  

nice little update 👍

[midudev]

@alireza-mh the problem is that what you're bundling is, probably, already compiled. For example, react and react-dom are already transpiled. Almost everything that's already in your node_modules is, in fact, already transpiled. That's why you're able to ignore them in your webpack.config.js.

So, your improvement of 1KB is from your codebase. Which, is not bad at all, in terms that your app is noticeable small.

[alireza-mh]

I removed node_module exclude from babel and ts loaders and faced the same bundle size.
(some of the packages like react-router-dom have esm folder)
I also checked this on the medium size project (400 KB minified and gzip) but the bundle size has been reduced by 2 KB.

[developit]

@alireza-mh Code imported from node_modules is ES5, regardless of whether it uses ES Modules. This is a common misconception - libraries like react-router-dom and redux don't actually provide ES2015, they just publish ES5 in a few different module formats. As such, they are entirely unaffected by this preset (whether you run them through Babel or not).

Regarding your repo, I can clarify something: the code isn't using async/await or Tagged Templates, which are the two syntax features that benefit most from this preset. The code is essentially written in ES2015 (classes, arrow functions), whereas this preset seeks to enable ES2017. It's likely the only output changes between preset-modules and preset-env for you are arrow functions being used more consistently and slightly worse JSX output (#4 will address).

In general we don't "modernize" code written in older syntax**, which means optimizations like preset-modules have no effect on that code. In order to see size gains from preset-modules, code needs to be written in ~ES2017 - the more the better.

** I have actually been looking into this space and am working on something.

[matzeeable]

Just came across this issue and just want to know if there are any news about your implementation, @developit ? 🙂