Skip to content
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

Tree-shaking drop useful code #2869

Closed
straccia17 opened this issue May 21, 2019 · 2 comments · Fixed by #2892
Closed

Tree-shaking drop useful code #2869

straccia17 opened this issue May 21, 2019 · 2 comments · Fixed by #2892

Comments

@straccia17
Copy link

straccia17 commented May 21, 2019

Tree-shaking algorithm seems to be too aggressive; it drops some useful code breaking runtime feature detection. The dropped code is part of a module of core-js (v2.6.7) installed as dependencies of @babel/polyfill (v.7.4.4).

  • Rollup Version: 1.12.3
  • Operating System (or Browser): macOS Sierra 10.13.6
  • Node Version: 8.11.1

How Do We Reproduce?

Clone this repository https://github.com/straccia17/rollup-treeshake-bug, execute yarn, then yarn run build.

Expected Behavior

Expected behavior is shown by dist/bundle-fixed.js files

Actual Behavior

Actual behavior is shown by dist/bundle.js files

Workaround

Set treeshake: false in rollup.config.js

@lukastaegert
Copy link
Member

Duplicates/related: #2540, #2273, #1771

The reason the code is removed is that Rollup always assumes that the code is running in a current generation environment when deciding if the call to a global function/contstructor has side-effects (such as throwing an error). This of course is a big problem for feature detection and finding solutions for this is definitely on my to-do list.

Even though there are already issues for this topic, I really like your reproduction as it shows nicely the code that is generated by core-js and we can readily use it to write tests.

Even though I stated otherwise in #2273, I think now that deoptimizing try-catch statements with regard to tree-shaking might actually be a good compromise way forward if we manage to track situations as in your example.

Alternative approaches are:

  • provide a user option to list or determine via a function files which should not be tree-shaken
  • open up the API to define side-effects for globals (more useful in marking stuff as side-effects-free IMO)
  • a special (comment) syntax to retain code (would rely on adoption by library authors, though. We might consider working with core-js if we want this).

@lukastaegert
Copy link
Member

#2892 will provide a solution for this that should work for you, comments welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants