Bump @wordpress/interface and other monorepo packages for Gutenberg 13.3.0 compat
#64093
Conversation
matticbot
added
the
[Status] Needs Review
|
This PR modifies the release build for editing-toolkit To test your changes on WordPress.com, run To deploy your changes after merging, see the documentation: PCYsg-mMA-p2 |
fullofcaffeine
changed the title
@wordpress/interface for Gutenberg 13.3.0 compat@wordpress/interface and other monorepo pacakges for Gutenberg 13.3.0 compat
fullofcaffeine
changed the title
@wordpress/interface and other monorepo pacakges for Gutenberg 13.3.0 compat@wordpress/interface and other monorepo packages for Gutenberg 13.3.0 compat
fullofcaffeine
added
the
caused-by-gutenberg-upgrade
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~5489 bytes added 📈 [gzipped]) Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~3849 bytes added 📈 [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 (~3958 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. |
|
Thanks for the help testing, @Addison-Stavlo! I also spent some time this morning testing this with @brookewp and the web app seems to work fine. However, we did see some issues on the The error is the following: In // react-with-styles-interface-css/dist/index.js
var _interopRequireDefault = __webpack_require__("../node_modules/@babel/runtime/helpers/esm/interopRequireDefault.js");
// _interopRequireDefaultg is not a function, but an object with a shape like: `Object { default: Getter, … }`.
// The `default` getter points to the actual function that should be called. We could force-fix it by calling
// `_interopRequireDefault.default` below, but obviously not a suitable fix as this is a third-party transitive dependency and the file is generated by WebPack.
// Errors here because `_interopRequireDefault` is not a function.
var _arrayPrototype = _interopRequireDefault(__webpack_require__("../node_modules/array.prototype.flat/index.js"));It appears as if the first require is wrong. I think the __interopRequireDefault should be inlined AFAIU, so that it can be used to get the default export? The same generated file on // react-with-styles-interface-css/dist/index.js
(...)
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { 'default': obj }; }
(...)Which works fine. This seems to be something that can be fixed at the Webpack level, though I'm not entirely sure yet. This also doesn't seem to be a hard blocker for releasing GB 13.3.0 as the web app seems to be working fine, but of course, it'd be best to get to the bottom of this issue and come up with a fix first. I'll spend some additional time on that today. cc @noahtallen and @Automattic/team-calypso-frameworks here as well to see if you have any additional ideas. |
|
I've spent most of my time today trying to get to the bottom of this. Kudos to @noahtallen for helping as well. I couldn't yet find a workaround, but I might be onto something as I found out it might be related to a new version of the To verify this:
This will force
So at least it seems we managed to narrow it down to a single package? Hopefully! 🤞🏻 I'll proceed to investigate what in Also, cc'ing @jsnajdr to see if you have any thoughts about this as well! 🙇🏻 |
|
I narrowed the issue down to this PR from The culprit seems to be the babel update in the aforementioned PR. It generates a var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault"); This is what triggers the error in the Calypso See why. It's probably due to some incompatibility with Calypso's Webpack configuration, I assume, but I couldn't pinpoint what, yet. This is what I'll try to find out next cc @noahtallen if you have any ideas! Before that PR in function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { 'default': obj }; } You can verify that with the following steps:
UPDATE: It's important to note, that |
I've further researched this and what I mentioned above It's not really the culprit, but a symptom of a change in babel. I've found that same change in dozens of other packages, too. The culprit seems to be the fact that those packages were built with a more recent version of babel that requires the I did find a hacky workaround - to use the yarn patch protocol to change the require line from: var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault"); To: var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault").default;This works. However, we'd have to patch dozens of different packages (mostly the new |
|
Oh, I see what might be wrong. Webpack is changing the require param to require the ESM version of the module for some reason: var _interopRequireDefault = __webpack_require__("../node_modules/@babel/runtime/helpers/esm/interopRequireDefault.js");We should get the CJS version instead, that correctly exports it in a compatible way: module.exports = _interopRequireDefault, module.exports.__esModule = true, module.exports["default"] = module.exports; I still don't know where in Webpack configuration is the issue, though. I'll keep looking. |
|
Seems it's related to the conditional exports and Webpack. It seems to be something similar to what was reported in this issue: iamkun/dayjs#492. |
I unfortunately don't have any immediate ideas! Since this is blocking Gutenberg release, my thought process is:
|
|
I've pinned However, for
Unfortunately, I couldn't pinpoint the root of the issue. It seems to be due to some unintended interaction with conditional exports. My hunch is that the Webpack+babel setup for Calypso can't handle packages that are pre-compiled with a more recent version of Babel that export the |
github-actions
bot
removed
the
[Status] Needs Review
|
Thanks for testing, Noah! This should unblock the release of GB 13.3.0 :) -- the pin of @mirka Also cc'ing you since I know you've recently worked on a Babel plugin and might have it fresh in your mind and maybe has some insights to share :) Thanks! 🙇🏻 |
|
@noisysocks may help with making sure that the version of |
|
I can't recall a lot of the original issue, but do we think the |
|
It also looks like we're still listing |
|
Great! I'll make sure that's updated in #77046 |
|
Yes I think |
Changes proposed in this Pull Request
@wordpress/interfaceand other monorepo packages to the latest versionsOriginal discussion: p1653583842699789-slack-CBTN58FTJ
This one's tricky because
@wordpress/interfaceisn't separately packaged in a way that lets us override a Core version. Instead, it's inlined by webpack rather than transformed into consuming a WP script by the dependency extraction plugin. Phew.WordPress/gutenberg/pull/40923 introduced the new stuff, but Help Center is still packaging an older, outdated version, which then tramples the
core/interfaceredux store namespace and lacks the new functions, which are called in theedit-sitepackages.Testing instructions
On a sandboxed site with the
gutenberg-edgesticker, build and run this version of ETK, and try to load the Site Editor.Before you would see an error on a call to
setDefaultComplementaryAreaand a WSOD in the Site Editor.Fixes #63944