-
Notifications
You must be signed in to change notification settings - Fork 123
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
Building/bundling react-tracking #127
Comments
Hey, why not leave If you look at the modules ecosystem this practice is almost non-existent for this reason. Would change library size from ~13kb to around ~3kb. I think userland is accustomed to having take care of polyfills |
Yea, ideally we would do that, but the tension was trying to keep the upgrade path as simple as possible since having It's been some time since then so maybe worth revisiting, especially if, as you said, this is the common practice in other module ecosystems. In fact, if you can point me to a few examples, maybe we can bundle in the same way so there isn't an exception here. I'd also be happy to review a PR to make this change if you're up for it, @dortzur . Thanks for commenting! |
Let's do it, polyfills are global and should be within consumer responsibility. |
Happy to accept a PR |
I'll create a PR soon, thanks. |
Done: #167 |
As per discussion in #119 we need a better way of bundling/building react-tracking. In v7.0.1 we had to move core-js@3 to a direct dependency, even though we don't need the entire library so that user-land doesn't need to adjust their babel configuration. This means we're reporting +40KB on bundlephobia which is misleading.
Maybe there will be some churn in the ecosystem as folks upgrade to core-js@3 and babel 7.4+ and better solutions/patterns will be established, but in the mean time, are there any ways to:
Any thoughts/ideas/other libs you know about that have solved this in a better way please feel free to chime in!
Some ideas:
The text was updated successfully, but these errors were encountered: