Parcel: Tree shaking fails for npm module `polished`

Created on 14 Feb 2019  ยท  5Comments  ยท  Source: parcel-bundler/parcel

๐Ÿ› bug report

I have included a test repository to showcase code and config.

๐ŸŽ› Configuration (.babelrc, package.json, cli command)

See test repo @ https://github.com/r0skar/polished-tree-shaking

Reproduction

  1. Clone the test repo @ https://github.com/r0skar/polished-tree-shaking
  2. Run yarn build.
  3. Compare parcel and webpack bundles in /dist.

๐Ÿค” Expected Behavior

Parcel should strip all unused modules from polished and be more or less the same size as the webpack bundle.

๐Ÿ˜ฏ Current Behavior

Parcel includes the whole polished bundle.

๐ŸŒ Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.11.0
| Node | 11.9.0
| Yarn | 1.13.0
| Operating System | Linux 4.20-7

Bug Stale ๐ŸŒณ Tree Shaking

Most helpful comment

This is caused by Parcel's (current) tradeoff for build speed instead of bundle size (running terser on the individual files rather than the whole bundle, as already discussed in #2310). webpack takes the other option leading to a smaller bundle.

This can be fixed by making Parcel run terser on the final output bundle instead, actually yielding better results than webpack! :

1.3K parcel.modified.js
2.9K webpack.js
 16K parcel.current.js

You can try this yourself by using the experimental Proof-of-Concept @mischnic/parcel-bundler instead of the parcel-bundler package.

@devongovett, in that issue you said:

There also wasn't a very big difference in output size that I saw, but perhaps you've run into something.

Here's an example
This is actually similar to the class example posted in the linked issue by kzc (functions marked as pure aren't eliminated across assets).
I still think tree shaking's primary goal should be bundle size, not build time (given that it's also not enabled by default โ€“ at least currently).

PS: Also, don't rely on the reported build size (normal or --detailed-...) by Parcel when using scope hoisting, it doesn't take tree shaking into account.

All 5 comments

You need to enable minification for tree shaking to work. Without --no-minify, I get 12.34 KB with your example.

You are right, the bundle size is drastically decreased when not using --no-minify, however if you look at the file, you will see that there is a lot of unused stuff still included. Also, the webpack version is about 7 times smaller at 1.8KB.

Is this maybe related to #2650? Not because of the environments but because of the dependencies that are loaded even if they are unused?

This is caused by Parcel's (current) tradeoff for build speed instead of bundle size (running terser on the individual files rather than the whole bundle, as already discussed in #2310). webpack takes the other option leading to a smaller bundle.

This can be fixed by making Parcel run terser on the final output bundle instead, actually yielding better results than webpack! :

1.3K parcel.modified.js
2.9K webpack.js
 16K parcel.current.js

You can try this yourself by using the experimental Proof-of-Concept @mischnic/parcel-bundler instead of the parcel-bundler package.

@devongovett, in that issue you said:

There also wasn't a very big difference in output size that I saw, but perhaps you've run into something.

Here's an example
This is actually similar to the class example posted in the linked issue by kzc (functions marked as pure aren't eliminated across assets).
I still think tree shaking's primary goal should be bundle size, not build time (given that it's also not enabled by default โ€“ at least currently).

PS: Also, don't rely on the reported build size (normal or --detailed-...) by Parcel when using scope hoisting, it doesn't take tree shaking into account.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dotdash picture dotdash  ยท  3Comments

will-stone picture will-stone  ยท  3Comments

algebraic-brain picture algebraic-brain  ยท  3Comments

termhn picture termhn  ยท  3Comments

medhatdawoud picture medhatdawoud  ยท  3Comments