There are both 06ee73755 and old ba3aee3a2 versions of packages and I'm unable to deduplicate them.

Looks like part of the problem there is that a version like 1.2.3-next.ba3aee3a2.0 compares as newer than 1.2.3-next.06ee73755.0 (because ba3aee3a2 > 06ee73755 as a string comparison), so it tends to incorrectly prefer the former for a caret version.

I fixed the questionable imports in WordPress/gutenberg#74530 and published a new next version, with the 06ee73755 hash.

Looks like you missed one: https://github.com/WordPress/gutenberg/pull/74530/changes#r2683062457 🙂

version like 1.2.3-next.ba3aee3a2.0 compares as newer than 1.2.3-next.06ee73755.0 (because ba3aee3a2 > 06ee73755 as a string comparison)

Well that's bad, and it's a bug in Gutenberg's version naming scheme for next packages. Let me see what we can do about it.

Looks like you missed one:

The moment-timezone omission was intentional, as it's the consumer (Jetpack) who should define an alias to a more optimized version.

On a second thought, I should probably have resolved this also to moment-timezone.js, and let consumers specify the alias for the name including the .js suffix.

Well that's bad, and it's a bug in Gutenberg's version naming scheme for next packages. Let me see what we can do about it.

One straightforward fix would be to name it like 1.2.3-next.$timestamp.$sha.0. Or, if these are always created via a build system and the build system has a monotonic build ID of some sort, that could work too.

The moment-timezone omission was intentional, as it's the consumer (Jetpack) who should define an alias to a more optimized version.

I don't see that documented in the package?

On a second thought, I should probably have resolved this also to moment-timezone.js, and let consumers specify the alias for the name including the .js suffix.

👍

One straightforward fix would be to name it like 1.2.3-next.$timestamp.$sha.0.

I'm trying to fix this in WordPress/gutenberg#74589, with a slightly different approach where the version number is 1.2.3-next.0+$sha. The .0 suffix added by Lerna should provide the auto-incrementing prerelease version number. And the commit SHA is only after the +, not affecting the semver comparison between two versions.

That sounds like it should work. 👍

Well, going forward anyway. 1.2.3-next.1 will be counted as being before 1.2.3-next.somesha by semver rules ("Numeric identifiers always have lower precedence than non-numeric identifiers.").

Well, going forward anyway. 1.2.3-next.1 will be counted as being before 1.2.3-next.somesha by semver rules

That's why I in the end merged a version that uses the 1.2.3-next.v.1 format. The v bit ensures that the version is always considered newer than any possible somesha one. And we can remove the v after the next public release that bumps the main 1.2.3 part of the version.

@anomiex @manzoorwanijk I updated this branch to the latest .next.v.0 packages and the results are very good: just one e2e failure for Jetpack sync. Can you determine if that's just a flaky test or is something still broken?

Yeah, the results are great. @anomiex Should we also see if we can clean up the .pnpmfile.cjs file?

I removed one unnecessary item from pnpmfile. For the real upgrade, we'll want most of what's left. We'd leave out the change to "next" on line 220. The extra .replace() on line 103 also isn't necessary, but won't hurt anything.

We'll also need the fix in projects/plugins/jetpack/tools/webpack.config.extensions.js, and the react deps in tools/js-tools/package.json thanks to @wordpress/stylelint-config adding a dep on @wordpress/theme.

Following WordPress/gutenberg#74576, we should be able to completely get rid of this file.

we should be able to completely get rid of this file.

The caveat is that you never use the default export of api-fetch, only the new named one. The bug with the default export is not yet fixed. To fix that, we'll need to start providing dual .d.ts files. Instead of the current build-types/index.d.ts, which is always interpreted as CJS, we'll need to have also build-types/index.d.mjs.

The caveat is that you never use the default export of api-fetch, only the new named one.

Yes, that is what I meant. Using named import can help us get rid of that file.

Following WordPress/gutenberg#74576, we should be able to completely get rid of this file.

I think we'll need to wait for a few WordPress releases though, until that change is in the Core-bundled copy of the lowest version we support.

I think we're good to close this now. Most of it was incorporated into #46647, and the rest of what we need from here is in #46430 (a989ca8).