Prevent duplicate Babel object spread helpers.

[sgomes]

Somewhere on the range of version 7.5 of Babel, the object spread helper was updated (to fix some edge cases, I believe).

When we upgraded our version of Babel to 7.5.5, it started trying to use the new helper to perform object spreads. This would have been fine, since the relevant package (transform-runtime) was part of the upgrade, but Babel sadly assumes that its version is older, instead of auto-detecting.

This change explicitly indicates which version of the transform-runtime we're using, fixing the issue. It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforementioned auto-detection, at which point we could remove the explicit definition.

CC @jsnajdr, who'd been looking at the bundle size increase with me.

Changes proposed in this Pull Request

• Explicitly indicate which version of Babel's transform-runtime we're using, to prevent helper duplication.

Testing instructions

There should be no special testing needed other than opening the live branch and ensuring nothing breaks after visiting a page or two. Babel transformations are so low level that a mistake would likely break everything.

To confirm the bundle size improvements, the icfy bot should be enough see my comments below.

[matticbot]

Test live: https://calypso.live/?branch=fix/duplicate-babel-spread-helpers

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~185 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-main                 -2431 B  (-0.1%)      +69 B  (+0.0%)
entry-domains-landing       +217 B  (+0.0%)     +116 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~2202 bytes removed 📉 [gzipped])

name                  parsed_size           gzip_size
plans                     -3157 B  (-0.6%)     -135 B  (-0.1%)
checkout                  -3157 B  (-0.3%)     -128 B  (-0.1%)
woocommerce               -2121 B  (-0.1%)      -45 B  (-0.0%)
settings                  -2121 B  (-0.4%)      -43 B  (-0.0%)
marketing                 -2121 B  (-0.3%)      -43 B  (-0.0%)
jetpack-connect           -2069 B  (-0.3%)      -30 B  (-0.0%)
posts-pages               -2062 B  (-0.6%)     -307 B  (-0.4%)
purchases                 -2041 B  (-0.2%)     -212 B  (-0.1%)
signup                    -1595 B  (-0.6%)      -21 B  (-0.0%)
themes                    -1570 B  (-0.4%)      -41 B  (-0.0%)
theme                     -1570 B  (-0.5%)      -41 B  (-0.0%)
plugins                   -1570 B  (-0.3%)      -41 B  (-0.0%)
export                    -1570 B  (-0.6%)      -41 B  (-0.1%)
email                     -1570 B  (-0.4%)      -41 B  (-0.0%)
domains                   -1570 B  (-0.2%)      -41 B  (-0.0%)
customize                 -1570 B  (-0.6%)      -41 B  (-0.1%)
help                      -1096 B  (-0.2%)      -32 B  (-0.0%)
account-close             -1096 B  (-0.3%)      -32 B  (-0.0%)
stats                     -1025 B  (-0.1%)     -179 B  (-0.1%)
settings-writing          -1025 B  (-0.2%)      -11 B  (-0.0%)
settings-security         -1025 B  (-0.4%)      -11 B  (-0.0%)
settings-performance      -1025 B  (-0.5%)      -11 B  (-0.0%)
settings-discussion       -1025 B  (-0.6%)      -11 B  (-0.0%)
post-editor               -1025 B  (-0.1%)      -27 B  (-0.0%)
comments                  -1025 B  (-0.2%)      -21 B  (-0.0%)
activity                  -1025 B  (-0.2%)     -179 B  (-0.2%)
login                      -977 B  (-0.7%)     -291 B  (-0.8%)
import                     -973 B  (-0.4%)       -1 B  (-0.0%)
gutenberg-editor           -952 B  (-0.1%)      -19 B  (-0.0%)
zoninator                  -474 B  (-0.2%)       -9 B  (-0.0%)
wp-super-cache             -474 B  (-0.2%)       -9 B  (-0.0%)
sites                      -474 B  (-0.5%)       -9 B  (-0.0%)
sensei                     -474 B  (-0.5%)       -9 B  (-0.0%)
preview                    -474 B  (-0.5%)       -9 B  (-0.0%)
posts-custom               -474 B  (-0.2%)       -9 B  (-0.0%)
people                     -474 B  (-0.1%)       -9 B  (-0.0%)
media                      -474 B  (-0.1%)       -9 B  (-0.0%)
hello-dolly                -474 B  (-0.5%)       -9 B  (-0.0%)
google-my-business         -474 B  (-0.2%)       -9 B  (-0.0%)
feature-upsell             -474 B  (-0.3%)       -9 B  (-0.0%)
earn                       -474 B  (-0.2%)       -9 B  (-0.0%)
concierge                  -474 B  (-0.2%)       -9 B  (-0.0%)
checklist                  -474 B  (-0.2%)       -9 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~812 bytes removed 📉 [gzipped])

name                                                         parsed_size           gzip_size
async-load-design-blocks                                         -2624 B  (-0.1%)      -74 B  (-0.0%)
async-load-my-sites-current-site-stale-cart-items-notice         -1096 B  (-0.9%)      -32 B  (-0.1%)
async-load-my-sites-current-site-notice                          -1096 B  (-0.7%)      -32 B  (-0.1%)
async-load-design                                                -1096 B  (-0.1%)      -32 B  (-0.0%)
async-load-blocks-inline-help-popover                            -1096 B  (-0.3%)      -32 B  (-0.0%)
async-load-my-sites-checklist-wpcom-checklist-component-jsx      -1028 B  (-0.7%)      +37 B  (+0.1%)
async-load-signup-steps-clone-point                               -551 B  (-0.3%)     -170 B  (-0.4%)
async-load-blocks-calendar-popover                                -551 B  (-0.2%)      -12 B  (-0.0%)
async-load-signup-steps-clone-destination                         -482 B  (-2.4%)      -12 B  (-0.2%)
async-load-signup-steps-plans-atomic-store                        -479 B  (-0.4%)     -159 B  (-0.6%)
async-load-signup-steps-plans                                     -479 B  (-0.3%)     -146 B  (-0.4%)
async-load-signup-steps-user                                      -478 B  (-0.5%)     -148 B  (-0.6%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[sgomes]

The matticbot numbers don't match my local ones. Investigating...

The fix is working correctly and spread helper duplication is no longer an issue after this PR. However, this doesn't appear to have produced noticeable size savings, according to the bot.

Edit: The bot appears to be wrong. See below.

[sgomes]

The numbers that icfy is reporting don't make sense to me.

If we follow the graph for entry-main, we see a big jump with the Babel upgrade:

According to the graph, it goes up from ~184000 to ~188000. From there, it stays at ~188000 until now.

When looking at the branch view for this PR, the entry-main size supposedly only goes down by 16 bytes (versus, presumably, the branch point for this PR, at ~188000 according to ICFY):

That would mean that it would still be at ~188000. However, downloading the relevant file from the live branch and gzipping it (at maximum compression, to match the supposed compression level default in gzip-size, which icfy indirectly uses) suggests otherwise, as it produces a file with ~182000 in my system.

In fact, I downloaded all relevant live branch versions and compared their gzipped sizes, making sure the gzip compression takes place in my machine, with the same settings for all of them, to ensure consistency. First, here are the links (you may have to rebuild the live branches):

Before Babel upgrade. Refers to commit 368279e.
After Babel upgrade. Refers to commit 5fcb020.
Parent commit. Refers to commit 5b9682f. Presumably what ICFY compares to in branch view?
This PR. Refers to commit 1020048e5d7b0e8a4c5d436bd013807c9d13ea23.

And here are the sizes after gzip -9:

before-babel-upgrade.js.gz    182389
after-babel-upgrade.js.gz     186250
parent.js.gz                  186577
this-pr.js.gz                 181832

As such, we're in a much better place after this PR than after the Babel upgrade (and even a bit better than before!), but icfy doesn't seem to reflect that.

CC @jsnajdr, as the main caretaker for icfy.

Edit: added the parent commit to the comparison, for good measure.

Edit 2: The branches above no longer reflect the current status of this PR, which has since been rebased, but the point they make still stands.

[sgomes]

Reviewers: to summarise, this PR is ready for review and does produce the expected bundle size improvements. See above for a deep dive into why that's the case despite what ICFY reports.

[ockham]

It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforementioned auto-detection, at which point we could remove the explicit definition.

Is there an upstream issue or something else we can link to from the code comment (to remind us at which point we'll be able to remove that line)?

[sgomes]

Is there an upstream issue or something else we can link to from the code comment (to remind us at which point we'll be able to remove that line)?

There is, sorry I forgot to include it! See babel/babel#10261

[simison]

Could you add a note to packages/calypso-build/CHANGELOG.md please?

[sgomes]

Could you add a note to packages/calypso-build/CHANGELOG.md please?

Sure thing, done!

[sgomes]

Rebased on master.

[sgomes]

Friendly ping for a review. Free performance gains right here! 😄

[jsnajdr]

Looks good, thanks for debugging this!

[sgomes]

Thanks for the review, @jsnajdr ! 🙇

[sgomes]

Confirmed a ~3KB difference in entry-main gzipped size while this was in staging (comparing to prod). Now deployed to prod.

@jsnajdr The ICFY graph for entry-main still doesn't show the expected numbers, if you ever have the time and impulse to investigate.

[jsnajdr]

The ICFY graph for entry-main still doesn't show the expected numbers, if you ever have the time and impulse to investigate.

Yep, putting that on my TODO list 🙂

[ntucker]

FYI: specifying a version of the runtime that the plugin is not aware of breaks it. It should probably just use all the features when it sees a version beyond its current one (maybe aside from a breaking version bump)