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

Add Babel with support for Node v12. #215

Merged
merged 5 commits into from
Sep 30, 2022
Merged

Conversation

jgerigmeyer
Copy link
Member

Fixes #205.

This is related to #206 as well, but does not add in CI to test Node version support.

rollup.config.js Outdated
@@ -1,44 +1,54 @@
import { babel } from "@rollup/plugin-babel";
import commonjs from "@rollup/plugin-commonjs";
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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?

Copy link
Member Author

@jgerigmeyer jgerigmeyer Sep 9, 2022

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:

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.

Copy link
Member

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?

Copy link
Member Author

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).

Copy link
Member Author

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.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@LeaVerou Adjusted in 862425c so that the original bundles are unchanged.

@LeaVerou
Copy link
Member

LeaVerou commented Sep 9, 2022

Hey, thanks! See one question, apart from that LGTM.
In future PRs please do try to separate style changes from the actual PR, as it makes reviewing harder.

Copy link
Member Author

@jgerigmeyer jgerigmeyer left a 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";
Copy link
Member Author

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

@jgerigmeyer
Copy link
Member Author

Hi @LeaVerou, any thoughts on this? Thanks!

@jgerigmeyer
Copy link
Member Author

Hi @LeaVerou, sorry to bother you, but I'm happy to wrap up this PR if you have any feedback? Thanks again!

@LeaVerou
Copy link
Member

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!

@jgerigmeyer
Copy link
Member Author

Oh no! Please take your time, and feel better soon!

@LeaVerou
Copy link
Member

LeaVerou commented Sep 29, 2022

Thank you!
I took a look and LGTM, my only comment would be since we're producing separate versions anyway, and doing all this work with Babel etc, we may as well add some more targets (older browsers that people may want to support) and produce a color.global.legacy.js build as well (or would it be color.legacy.global.js?)
(Not crazy old like IE11 though)

@jgerigmeyer
Copy link
Member Author

jgerigmeyer commented Sep 30, 2022

Thank you! I took a look and LGTM, my only comment would be since we're producing separate versions anyway, and doing all this work with Babel etc, we may as well add some more targets (older browsers that people may want to support)

@LeaVerou Sure! I added the browserslist defaults in d008c58 -- this is the current list that it's supporting.

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.

and produce a color.global.legacy.js build as well (or would it be color.legacy.global.js?) (Not crazy old like IE11 though)

Done -- here's the full list:

dist/color.global.js
dist/color.global.min.js
dist/color.js
dist/color.min.js
dist/color.cjs
dist/color.min.cjs
dist/color.global.legacy.js
dist/color.global.legacy.min.js
dist/color.legacy.js
dist/color.legacy.min.js
dist/color.legacy.cjs
dist/color.legacy.min.cjs

The current bundles are unchanged:

color.global.js: 107.94 kB → 34.67 kB (gzip)
color.js: 104.35 kB → 34.23 kB (gzip)
color.cjs: 104.42 kB → 34.27 kB (gzip)
color.min.cjs: 41.66 kB → 16.5 kB (gzip)
color.min.js: 41.59 kB → 16.48 kB (gzip)
color.global.min.js: 41.6 kB → 16.52 kB (gzip)

Here are the current file sizes of the new bundles:

color.global.legacy.js: 167.56 kB → 46.34 kB (gzip)
color.legacy.js: 158.47 kB → 45.85 kB (gzip)
color.legacy.cjs: 158.55 kB → 45.89 kB (gzip)
color.legacy.min.js: 58.2 kB → 22.27 kB (gzip)
color.legacy.min.cjs: 58.27 kB → 22.3 kB (gzip)
color.global.legacy.min.js: 58.22 kB → 22.37 kB (gzip)

For comparison, here's what it would be if we changed to add support for > 0.2% usage:

color.global.legacy.js: 313.81 kB → 80.41 kB (gzip)
color.legacy.js: 297.66 kB → 79.41 kB (gzip)
color.legacy.cjs: 297.74 kB → 79.44 kB (gzip)
color.legacy.min.js: 99.7 kB → 38.08 kB (gzip)
color.legacy.min.cjs: 99.77 kB → 38.1 kB (gzip)
color.global.legacy.min.js: 99.64 kB → 38.23 kB (gzip)

@LeaVerou LeaVerou merged commit 50891cc into color-js:main Sep 30, 2022
@LeaVerou
Copy link
Member

LGTM, thank you for working on this! Just merged. :)

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

Successfully merging this pull request may close these issues.

Avoid Nullish coalescing operator to support old Node.js
2 participants