fix(deps): update wordpress monorepo (take 2)

[sirreal]

Second attempt at #41207 after it was reverted in #41974

Reverted due to:

Uncaught TypeError: Cannot read property 'parentNode' of null

Apparently Coming from here:
https://github.com/WordPress/gutenberg/blob/c9ce32fb147b864d7f1d15df8ede97699ded4e91/packages/components/src/popover/index.js#L331-L335

[matticbot]

Test live: https://calypso.live/?branch=revert-41974-revert-41207-renovate/wordpress-monorepo

[matticbot]

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

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

name                   parsed_size           gzip_size
entry-gutenboarding       +80231 B  (+4.5%)   +16404 B  (+3.4%)
entry-main                   +49 B  (+0.0%)      +16 B  (+0.0%)
entry-login                  +45 B  (+0.0%)       +8 B  (+0.0%)
entry-domains-landing        +21 B  (+0.0%)       +5 B  (+0.0%)

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

Sections (~2607 bytes added 📈 [gzipped])

name              parsed_size           gzip_size
post-editor           +7748 B  (+0.4%)    +1478 B  (+0.3%)
checkout              +3562 B  (+0.3%)     +563 B  (+0.2%)
gutenberg-editor      +3406 B  (+0.4%)     +566 B  (+0.3%)

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

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.

[sirreal]

Rebased.

[sirreal]

This seems to have been introduced here in WordPress/gutenberg#19344:

WordPress/gutenberg@ef73ed0#diff-ccdf667da5123277e79748286c32fda7R328-R333

			if ( __unstableBoundaryParent ) {
				boundaryElement = containerRef.current.closest(
					'.popover-slot'
				).parentNode;
			}

There's a bug, .closest can (and does in this case) return null.

[sirreal]

I've opened WordPress/gutenberg#22264 for the the Popover issue.

[Addison-Stavlo]

Nice, with WordPress/gutenberg#22264 now merged this should be about ready for another chance at deployment?

Looking at the conflict in yarn.lock:

Master:

"@wordpress/icons@*":
  version "1.4.0"
  resolved "https://registry.yarnpkg.com/@wordpress/icons/-/icons-1.4.0.tgz#805732a5527eb2178bd97b53decac67451b2b1b3"
  integrity sha512-YNW1ocZddZ6c40QHiR/Q3yIPYzh4Fdcq/J4sJIkegwqEXltVknYa90RNaDG9xr+qMvXN5/wotYaLA+AP6pUfHA==
  dependencies:
    "@babel/runtime" "^7.9.2"
    "@wordpress/element" "^2.13.1"
    "@wordpress/primitives" "^1.4.0"

"@wordpress/icons@1.2.0", "@wordpress/icons@^1.2.0":
  version "1.2.0"
  resolved "https://registry.yarnpkg.com/@wordpress/icons/-/icons-1.2.0.tgz#734c8d684c8a02d688e8d96e5ce57de574d5c388"
  integrity sha512-9QuXr1FA4byrlQ5SQWoVE/BMzoDqhX1AYuzZeZh9aa9dlHLo8cMQ0hGhbgtrv8GsztRniRZ/ms7UqlkFxXgD8g==
  dependencies:
    "@babel/runtime" "^7.8.3"
    "@wordpress/element" "^2.12.0"
    "@wordpress/primitives" "^1.2.0"

Here:

"@wordpress/icons@*", "@wordpress/icons@1.4.0", "@wordpress/icons@^1.4.0":
  version "1.4.0"
  resolved "https://registry.yarnpkg.com/@wordpress/icons/-/icons-1.4.0.tgz#805732a5527eb2178bd97b53decac67451b2b1b3"
  integrity sha512-YNW1ocZddZ6c40QHiR/Q3yIPYzh4Fdcq/J4sJIkegwqEXltVknYa90RNaDG9xr+qMvXN5/wotYaLA+AP6pUfHA==
  dependencies:
    "@babel/runtime" "^7.9.2"
    "@wordpress/element" "^2.13.1"
    "@wordpress/primitives" "^1.4.0"

Rebased in favor of the latter.

Is there anything else this needs to wait on at this point?

[scinos]

Rebased to solve conflicts in yarn.lock

[sirreal]

Is there anything else this needs to wait on at this point?

We need a new release of @wordpress/packages. The fix hasn't been published yet.

I check https://unpkg.com/browse/@wordpress/components/src/popover/index.js to see whether it includes that change we need (latest is 9.5.0)

[sirreal]

Somehow I've apparently managed to mangle this. Let's proceed with Renovate's #42031