-
-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add Babel with support for Node v12. #215
Conversation
rollup.config.js
Outdated
@@ -1,44 +1,54 @@ | |||
import { babel } from "@rollup/plugin-babel"; | |||
import commonjs from "@rollup/plugin-commonjs"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why we need this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this is currently setup to use @babel/preset-env with useBuiltIns: 'usage'
, it automatically pulls in any necessary polyfills from core-js. Since we want to include those polyfills in the distributed bundles, we need to use this plugin to convert them from CommonJS modules to ES6, so Rollup can include them. See: https://github.com/rollup/plugins/tree/master/packages/node-resolve#using-with-rollupplugin-commonjs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks. Does it only pull in polyfills that are actually needed or everything? Do you have any sense of how much this increases the size of the bundles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it only pull in polyfills that are actually needed or everything?
It only pulls in the polyfills that are necessary for the target (node v12) based on the code actually used. In this case, I think it's these two small polyfills:
- https://github.com/zloirock/core-js/blob/master/packages/core-js/modules/es.error.cause.js (used throughout)
- https://github.com/zloirock/core-js/blob/master/packages/core-js/modules/es.reflect.to-string-tag.js (only used by
space-accessors.js
)
Do you have any sense of how much this increases the size of the bundles?
It increases the bundle size by about 44% (non-minified) or 30% (minified). The large majority of this increase is syntax re-writing by Babel, not the core-js polyfills themselves.
Before:
Created bundle color.global.js: 107.94 kB → 34.67 kB (gzip)
Created bundle color.js: 104.35 kB → 34.23 kB (gzip)
Created bundle color.cjs: 104.42 kB → 34.27 kB (gzip)
Created bundle color.min.js: 41.59 kB → 16.48 kB (gzip)
Created bundle color.global.min.js: 41.6 kB → 16.52 kB (gzip)
Created bundle color.min.cjs: 41.66 kB → 16.5 kB (gzip)
After:
Created bundle color.global.js: 155.44 kB → 44.57 kB (gzip)
Created bundle color.js: 151.04 kB → 44.22 kB (gzip)
Created bundle color.cjs: 151.12 kB → 44.25 kB (gzip)
Created bundle color.min.js: 54.88 kB → 21.45 kB (gzip)
Created bundle color.global.min.js: 54.89 kB → 21.55 kB (gzip)
Created bundle color.min.cjs: 54.95 kB → 21.48 kB (gzip)
If you're concerned about that, I suppose another option would be to add new bundles that have support for older versions of Node, and not run everything through Babel? If you'd like to go that route, I'm happy to adjust this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, so sorry for the delay, I didn't get a notification and only saw you had responded when I manually visited the PR to see if there were any updates. Ouch, that's quite an increase. Yes, I think the way to go would be to have separate bundles. In that case we could even support somewhat older browsers too in those bundles, what do you think?
Is there a good naming convention for the transpiled bundles that we could follow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the way to go would be to have separate bundles. In that case we could even support somewhat older browsers too in those bundles, what do you think? Is there a good naming convention for the transpiled bundles that we could follow?
@LeaVerou I agree, that seems like a good way to go. Are you thinking multiple new bundles with different levels of browser/node support? Or one "legacy" bundle that has support for older platforms?
I think I'd lean toward the latter, and probably I'd propose something like color-legacy.js
? 🤷
I'll do a quick update to try that out with Node 12 -- let me know if there are other platforms you think should be targeted (see: https://babeljs.io/docs/en/options#targets).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(The most recent commit doesn't work -- I'll push a fixed version shortly.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks! See one question, apart from that LGTM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In future PRs please do try to separate style changes from the actual PR, as it makes reviewing harder.
Reverted style changes and squashed commits. 👍
rollup.config.js
Outdated
@@ -1,44 +1,54 @@ | |||
import { babel } from "@rollup/plugin-babel"; | |||
import commonjs from "@rollup/plugin-commonjs"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this is currently setup to use @babel/preset-env with useBuiltIns: 'usage'
, it automatically pulls in any necessary polyfills from core-js. Since we want to include those polyfills in the distributed bundles, we need to use this plugin to convert them from CommonJS modules to ES6, so Rollup can include them. See: https://github.com/rollup/plugins/tree/master/packages/node-resolve#using-with-rollupplugin-commonjs
Hi @LeaVerou, any thoughts on this? Thanks! |
Hi @LeaVerou, sorry to bother you, but I'm happy to wrap up this PR if you have any feedback? Thanks again! |
Sorry @jgerigmeyer, I had a deadline, then travel, and then got covid 🤦🏽♀️ I'm still in quarantine, but will try to review this soon. So sorry about the delay, please don't take this as meaning anything about how interested we are in merging this PR! |
Oh no! Please take your time, and feel better soon! |
Thank you! |
@LeaVerou Sure! I added the browserslist Do you have particular browsers in mind? I wasn't sure where to make the cutoff, and if we go much further back (e.g. Android 4 or iOS 12) then the bundles roughly double in size.
Done -- here's the full list:
The current bundles are unchanged:
Here are the current file sizes of the new bundles:
For comparison, here's what it would be if we changed to add support for
|
LGTM, thank you for working on this! Just merged. :) |
Fixes #205.
This is related to #206 as well, but does not add in CI to test Node version support.