-
Notifications
You must be signed in to change notification settings - Fork 2k
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 core-js@3. #38660
Upgrade to core-js@3. #38660
Conversation
client/boot/polyfills.js
Outdated
@@ -1,24 +1,23 @@ | |||
/** | |||
* External dependencies | |||
*/ | |||
import '@babel/polyfill'; | |||
import 'core-js/stable'; | |||
import 'regenerator-runtime/runtime'; |
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.
Note: we need to depend on this directly now, as it used to be included by @babel/polyfill
, but it's not in core-js/stable
. See https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#babelpolyfill
|
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 boot/polyfills
module would deserve its own NPM package (@automattic/calypso-polyfills
?) 🙂 We'll need to import it in the wp-desktop
app, too, together with starting to build it with calypso-build
, and remove custom/duplicate code like parts of Automattic/wp-desktop#733
13b99d4
to
64035a8
Compare
The following code produces very different output between production and this branch: var x = "By continuing, you agree to our {{tosLink}}Terms of Service{{/tosLink}}.";
x.split( /(\{\{\/?\s*\w+\s*\/?\}\})/g ); This generates an array with 5 items (as expected) in production, and 143 (!) in this branch. There appears to be a bug in |
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~31556 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~29751 bytes removed 📉 [gzipped])
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 (~6529 bytes added 📈 [gzipped])
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. Generated by performance advisor bot at iscalypsofastyet.com. |
Back on track, after updating to |
@jsnajdr This PR appears to significantly inflate bundle sizes, upwards of 14KB (compressed!) for most entry points (I verified the bot's results and they appear to be correct). If we are to deploy this, we should probably prioritise getting rid of the remnants of |
Yes, that's expected 🙂 Let's remove the offending libraries in the following few days. |
ffb4577
to
fda33e6
Compare
After rebasing, all tests are now green. |
fda33e6
to
7437de0
Compare
Rebased again, this time due to #38688. |
The latest bundle size reports seem a bit odd. Removed 56k from entrypoints? Maybe the report is just bad? |
Yup, totally agreed
Maybe we could offer assistance to maintain it? Or do you think forking is worth it? |
After a fun debugging session, I discovered that we need to specify When listing the expanded available polyfills that |
I'm just not sure our use-case matches anyone else's exactly. What we want, and probably what a lot of folks want, is for the package to include sources that they can compile, so that polyfills are all taken care of as part of the holistic build process. However, what those sources should look like is different to everyone. For example, a lot of folks use Perhaps we could agree on shipping an "ES20xx" build in the package, but which "xx"? And should it include JSX as-is, or have it transpiled (and if so, using which options?) The fundamental issue is that there is no universal "source" that can be distributed to every project in such a way that it can always be compiled, so they decided to distribute a "compiled" version, and in doing so tied their library to |
Other stable polyfills we were losing because of
|
This helps avoid the globalThis workaround.
Excellent sleuthing, @jsnajdr 👍 I've switched back to |
After researching The thing that makes this possible is the fact that when transpiling dependencies, both CRA and Calypso use env preset with the The Calypso dependencies are transpiled with the babel.dependencies.config.js config. And it also needs update from |
The best common denominator at this moment seems to be standard JavaScript in the latest version (at package publish time). That's also how CRA and Calypso transpile their It shouldn't be hard to reach agreement on that. I'd prefer to avoid creating our own fork of |
Fair enough, I'll work on a PR and pitch the idea to the project 👍 |
Looking at |
Good catch! Fixed. |
@jsnajdr : The polyfills have been package-ified! |
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.
This is awesome ❤️ I love how the core-js
package and other polyfills got pushed down to a leaf package.json
.
5b912bb
to
bd25dee
Compare
bd25dee
to
5a01300
Compare
webpack.config.js
Outdated
@@ -79,6 +79,7 @@ const nodeModulesToTranspile = [ | |||
'striptags/', | |||
'unicode-match-property-ecmascript/', | |||
'unicode-match-property-value-ecmascript/', | |||
'gridicons/', |
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.
Is the gridicons/
transpilation related to the CoreJS 3 upgrade?
In any case, you need to also add @automattic/calypso-polyfills
to the whitelist to make it all work.
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.
Possibly unrelated. This was a fix that was required for production builds to work locally for me, but it doesn't seem to be an issue outside of my machine. I'll remove that and double-check that everything still works fine.
webpack.config.js
Outdated
@@ -64,6 +64,7 @@ const nodeModulesToTranspile = [ | |||
// general form is <package-name>/. | |||
// The trailing slash makes sure we're not matching these as prefixes | |||
// In some cases we do want prefix style matching (lodash. for lodash.assign) | |||
'@automattic/calypso-polyfills', |
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.
There needs to be a trailing slash here. If there isn't one, the code would also match a package name like @automattic/calypso-polyfills-blah-blah
🙂
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.
Oops, I missed that, sorry!
It's starting to take a toll to still use
core-js@2
, since we're missing important features:Object.fromEntries
,Array.flat
,globalThis
,URL
, to name a few. We've been adding support for some of these with individual polyfills, but it's time to take the leap and move over tocore-js@3
, to ensure our development environment stays representative of the current state of the JS spec.This will initially result in some code duplication, as unfortunately we use several packages with a hardcoded dependency on
core-js@2
. Hopefully, over time, we'll be able to replace these packages with more modern ones, or update them ourselves to be compatible withcore-js@3
.Changes proposed in this Pull Request
core-js
package to the current version.core-js
version in the babel config.@babel/polyfill
and usecore-js
directly.@webcomponents/url
).boot/polyfills
rather than its own code.Testing instructions
This change affects all of Calypso, so please be sure to try using it as much as possible both in newer browsers, which should use the evergreen build (that includes fewer polyfills); and in older browsers (particularly IE11), which should use the fallback build (that includes all polyfills).
Potential areas of interest: anything that does URL processing (e.g. sharing from Reader), and anything that uses
globalThis
(e.g. language switching).