Regression in script dependencies in 19.5.0

[sgomes]

Description

#65292 introduced a mechanism to avoid adding wp-polyfill as a dependency to every package, based on what syntax features are actually in use. Unfortunately, a regression was since introduced where pretty much all packages now end up depending on wp-polyfill again.

The cause behind this is that new features are now being polyfilled, specifically new methods in arrays and sets.

Full list of polyfills

es.array.to-reversed for {"chrome":"109"}
es.array.to-sorted for {"chrome":"109"}
es.array.to-spliced for {"chrome":"109"}
es.array.with for {"chrome":"109"}
es.array-buffer.detached for {"chrome":"109"}
es.array-buffer.transfer for {"chrome":"109"}
es.array-buffer.transfer-to-fixed-length for {"chrome":"109"}
es.map.group-by for {"chrome":"109","ios":"17.5","safari":"17.5"}
es.object.group-by for {"chrome":"109","ios":"17.5","safari":"17.5"}
es.promise.with-resolvers for {"chrome":"109"}
es.regexp.flags for {"chrome":"109"}
es.set.difference.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.intersection.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.is-disjoint-from.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.is-subset-of.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.is-superset-of.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.symmetric-difference.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.set.union.v2 for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
es.string.is-well-formed for {"chrome":"109"}
es.string.to-well-formed for {"chrome":"109"}
es.typed-array.to-reversed for {"chrome":"109"}
es.typed-array.to-sorted for {"chrome":"109"}
es.typed-array.with for {"chrome":"109"}
web.dom-exception.stack for {"android":"129","chrome":"109","chrome-android":"129","edge":"127","ios":"17.5","opera":"113","opera-android":"80","safari":"17.5","samsung":"25"}
web.structured-clone for {"android":"129","chrome":"109","chrome-android":"129","edge":"127","firefox":"129","ios":"17.5","opera":"113","opera-android":"80","safari":"17.5","samsung":"25"}
web.url.can-parse for {"chrome":"109"}
web.url.parse for {"chrome":"109","ios":"17.5","opera-android":"80","safari":"17.5","samsung":"25"}
web.url-search-params.delete for {"chrome":"109"}
web.url-search-params.has for {"chrome":"109"}
web.url-search-params.size for {"chrome":"109"}

These new methods are not actually in use in all of these packages (if any?), but are being marked as needed due to severe limitations in babel. Essentially, and as far as I can tell, any code that uses an Array will be marked as needing all of the array methods, even if they're not being used anywhere.

There are two ways we could approach this:

• We could exclude the problematic polyfills explicitly in polyfill-exclusions.js
• We could roll back the package updates that triggered the change

Any of the above options will leave the methods unpolyfilled, however, and thus unavailable for general use in Gutenberg.

Beyond this, we should probably consider adding a CI job to detect similar issues in the future (e.g. by checking that a selection of basic packages, like hooks and i18n, don't get a dependency on wp-polyfill).

I'd like to hear any of your thoughts in how to tackle this!

Step-by-step reproduction instructions

1. Build Gutenberg
2. Analyse the index.min.asset.php files for packages like i18n or hooks, which shouldn't require polyfills

Screenshots, screen recording, code snippet

No response

Environment info

• Gutenberg 19.5.0 and later.

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[sgomes]

Adding a few folks that have an interest here, from previous work on this:

@anomiex @gziolo @jsnajdr @sirreal @swissspidy

[swissspidy]

Yikes! Do we know when this regressed and whether this is in WP 6.7? We‘d need to prioritize it in that case.

[sgomes]

Yikes! Do we know when this regressed and whether this is in WP 6.7? We‘d need to prioritize it in that case.

@swissspidy: As far as I can tell, it regressed with #65926, i.e. commit 72d2ff4. I'm not sure how to check whether that was part of WP 6.7 😕

[jsnajdr]

#65926 was not backported to wp/6.7 and the relevant packages still have the old versions in that branch. So we're dealing with a regression that is present only in trunk and in the Gutenberg plugin.

[anomiex]

There are two ways we could approach this:

• We could exclude the problematic polyfills explicitly in polyfill-exclusions.js
• We could roll back the package updates that triggered the change

Another option to take care of a big chunk of the problem would be to drop support for chrome 109 (i.e. add not chrome 109 to the browserslist config). It seems likely it's still at > 1% due to it being the last version of Chrome supporting Windows 7 and 8.

[sgomes]

Another option to take care of a big chunk of the problem would be to drop support for chrome 109 (i.e. add not chrome 109 to the browserslist config). It seems likely it's still at > 1% due to it being the last version of Chrome supporting Windows 7 and 8.

Unfortunately, this kind of thing is an all-or-nothing affair, so we'd still need a way for common features not to be polyfilled at all 😕

Dropping support for chrome 109 while simultaneously excluding es.map.group-by and es.object.group-by might do the trick?

[jsnajdr]

Dropping support for Chrome 109 means that as soon as we start using array.toSorted their Gutenberg will start crashing and they will be completely cut off. I think the benefit is not big enough to justify this.

[sgomes]

We don't really have any great solutions if we want to be able to use array.toSorted. We'd either need to polyfill it for every package (i.e., maintain the status quo); or we'd need to somehow improve Babel's feature detection to check whether it's actually being used, rather than checking for whether any arrays are being used.