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

String(Symbol()) is removed upon treeshaking #2790

alippai opened this Issue Apr 3, 2019 · 3 comments


None yet
3 participants
Copy link

alippai commented Apr 3, 2019

  • Rollup Version:
  • Operating System (or Browser):
  • Node Version:

How Do We Reproduce?

  1. Add core-js@3.0.0
  2. Use rollup
  3. zloirock/core-js#513 happens

Expected Behavior

String(Symbol()) shouldn't be removed as they can easily throw

Actual Behavior

They are removed


This comment has been minimized.

Copy link

lukastaegert commented Apr 3, 2019

as they can easily throw

not to my knowledge in an environment which is compliant with the current ES2018 spec. Which is not to dismiss this issue but to put it into perspective. Rollup currently assumes that all builtins behave according to the latest spec.

And this is usually what the user wants EXCEPT inside polyfills. If every invocation of Symbol would be considered a side-effect, this would make Symbol something that people should definitely avoid ever using unless forced to.

So this is more about the issue of providing a useful fallback behaviour for polyfills (BTW all of these issues stem from IE11...). I have several ideas but nothing has been investigated further yet.


This comment has been minimized.

Copy link
Contributor Author

alippai commented Apr 3, 2019

Wow, thank you for sharing the context of the issue!

This specific incompatibility between Rollup and core-js will be fixed upon the next core-js release.


Looking for a workaround myself (without patching core-js or Rollup) I was expecting a blacklist option for the tree-shaking algorithm, where I can flag functions (names) with known side-effects (in this case Symbol()). I know this wouldn't be an optimal solution either, but maybe it even helps with propertyReadSideEffects (which could default to false).
// @rollup-side-effect-next-line is an other option (which wouldn't help in my case)

My solution

To resolve my issue I didn't bundle core-js, but added it separately to the HTML. It's a separate vendor package with separate release cycle, already bundled and it's huge alone (30+kB).


This comment has been minimized.

Copy link

GrosSacASac commented Apr 9, 2019

related #1771

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.