-
Notifications
You must be signed in to change notification settings - Fork 384
Upgrade to babel 7 #273
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
Upgrade to babel 7 #273
Conversation
Awesome, thanks! Let me confirm that builds still work tonight and I'll merge. Looks good just from code though. I especially want to confirm that |
It looks like this is pulling in a few additional polyfills @ignatiusreza. After
this branch:
Would you mind digging into that a little bit? Ideally this wouldn't increase bundle size, consumers of the library should supply polyfills. |
Sure, i'll try to dig into it |
before: 7123 Container.js 647 index.js 7772 Sticky.js after: 5113 Container.js 637 index.js 5874 Sticky.js
spent some time trying to figure it out.. I have a good news and a bad news.. the bad news: rather than polyfill, I think the extra bytes came from babel runtime itself doing more check than it was before.. the good news: babel 7 comes with build size different:
as seen above, the build size is now slightly smaller than master.. though, that's not counting the imported bytes from I did a quick check into some other popular packages, and found that at least react-redux and react-router uses the same technique.. meaning that the extra bytes from runtime will be shared across these packages.. wdyt? |
Cool, looks like that saves a few hundred bytes on each file compared to before! Looks good to me. |
This is a first step PR for fixing travis build (second PR at #274)..
Both webpack and webpack-dev-server in master depends transitively on
upath@1.0.2
which locked node engine at>=4 <=9
, even though travis is usingv11.10.0
..