-
Notifications
You must be signed in to change notification settings - Fork 4.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
Minimal node and npm upgrade #52363
Minimal node and npm upgrade #52363
Conversation
faf7769
to
73379ae
Compare
Flaky tests detected in 8c91d9c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5512940997
|
@youknowriad Since we now have access to |
@noahtallen Sure, assuming it doesn't break anything (tests or whatever), I think it's important that we ship this PR quickly to avoid the constant rebases. |
If you like, I can push a commit to try it today, and then revert if it causes issues :) |
I've pushed the dedupe, let's see how it goes |
@noahtallen there are some very minor failures in the unit tests and one failure in the test that checks the validity of the package-lock.json. I'm certain that it's fixable and that it's probably due to the job itself but for the sake of not blocking this I'm considering reverting the dedupe to leave it to its own PR. WDYT. |
I was able to update the unit test snapshots and they look pretty minor -- let me see if I can also find a quick fix for the package-lock issue |
The package-lock issue is weird; it's changing the lockfile versions for a few of the internal react-native packages like I wonder if this issue will happen consistently |
What's certain is that It didn't happen before the dedupe. I wonder if it's related to the "peers" issue in native modules. |
Hm, I feel like it'd be something else. Since there are other peer dependency issues in the repo with other packages, I don't think the react-native packages would be unique. Another point of data, the version set before the dedupe was also 1.98.0. So it feels related to something internal to npm somehow |
yeah maybe an npm bug. |
I think the info about Lerna and updating dependencies is outdated. It applies to the old version of npm (6.x) which didn't support workspaces (packages) and had many bugs when it comes to maintaining the package tree and deduplicating it. With the latest npm version, after the upgrade, |
@noahtallen Great catch on the rnmobile update, it seems like all is good now. Thanks for the update here. |
@@ -32,7 +32,7 @@ exports[`DependencyExtractionWebpackPlugin Webpack \`combine-assets\` should pro | |||
`; | |||
|
|||
exports[`DependencyExtractionWebpackPlugin Webpack \`dynamic-import\` should produce expected output: Asset file 'main.asset.php' should match snapshot 1`] = ` | |||
"<?php return array('dependencies' => array('wp-blob'), 'version' => 'c8be4fceac30d1d00ca7'); |
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.
I was curious why a Node upgrade would cause change of production JS assets. That shouldn't happen. And tracked it down to caniuse-lite
upgrade:
- what actually changed in the bundle is that
globalThis.webpackChunk
references changed toself.webpackChunk
. - they changed because our supported browsers no longer all support
globalThis
. - the browser that doesn's support
globalThis
isand_uc
-- Android UC browser. - we support this browser because it has more than 1% usage.
- it's only in the latest
caniuse-lite
data where this browser went over 1% -- it's 1.044%. It was under 1% in the old version.
A standalone PR that updates caniuse-lite
(and maybe also pins it in package.json
?) would be nice, but not necessary.
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.
I merged the caniuse-lite
/browserslist
/core-js
upgrade separately in #52420. The newly supported browser (and_uc
) caused different output for webpack runtime code (the hashes in test snapshots agree!), and also new CSS autoprefixes like -webkit-margin-before
for margin-block-start
.
And now we can see an example of this in this very PR: #52363 (comment) The |
Interesting. Thanks for digging there @jsnajdr |
So it doesn't seem like there's any blockers left. After some discussions with @kevin940726 and @desrosj We're planning on landing the upgrade by 6.3 RC1 (so in 10 days approx) to avoid too much disruptions for developers and most of us will switch to 6.4 work at that time. Core and Gutenberg don't necessarily need to be updated at the same time but it's a good thing to try to synchronize. |
Indeed -- I tried regenerating the lockfile from scratch yesterday out of curiosity, and ran into a ton of CI issues due to the updates. |
f842b99
to
8c91d9c
Compare
I rebased to resolve conflicts and to incorporate @jsnajdr's changes. |
Hope it didn't cause too much trouble with updating the |
Not a problem! Turns out there's another lockfile conflicts anyways. Not sure if there's a better way to do this, but I just dropped all the package-lock changes that existed already, and ran I often rely on |
I'd just like to get some clarification on this to make sure there's nothing being missed and that the reasoning is clear. I've updated wordpress-develop#4028 to be up to date with the current state of I don't love that the two different code bases will be using different versions. The contributor experience of having to remember to switch versions each time you change from the Core to Gutenberg repos seems like it could cause a lot of strange scenarios. I guess, as long as we continue to run tests on 16 in the Gutenberg repository, we can manage for now though. Testing in 16.x would ensure merging code into WordPress Core will go smoothly. I'm sure we'll encounter some strangeness between 16 and 18 at some point. It would also be great to not enforce 18.x here and still allow contributors to use 16.x if desired. I'm not sure if there are any unforeseen consequences of that, though. This would allow anyone bouncing between Core and Gutenberg to remain on 16 without having to change. Finally, this change will need to be communicated to the development community at large. I'll draft a post for this early next week. |
I did want to mention using |
Totally agree. I think detailing this in the post is an easy win. I also have my machine set up to automatically detect an |
@youknowriad just reminding about earlier point and especially lack of security upgrades beyond 2023-09-11 is kind of a bummer:
Edit: just saw https://make.wordpress.org/core/2023/08/09/updating-wordpress-to-use-more-modern-versions-of-node-js-npm/ posted, with explanation. :-) All good, thanks for your work folks! |
This PR includes the minimal changes to the repository to upgrade NodeJS and NPM. There are other things we could do (adopt workspaces, update the packages "engine" config... but let's leave that for a separate PR #48950)
Why
It is becoming very urgent to update node and npm. Without mentioning the benefits of the upgrade in terms of features and performance, we're now starting to be blocked as a lot of packages have updated their minimum supported versions for node and npm. (I've been trying to use yjs in a PR and got stuck because of this).
Jobs
I've fixed all the CI jobs, except one (Compressed size) but we can ignore this one, it's failing because it's running
npm install
in trunk with the new npm version. It will fix itself after merge.Testing instructions
npm run dev
or any of the commands you use daily to work in Gutenberg.