-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[Discussion] Upgrade node
and npm
to latest LTS versions
#48588
Comments
In relation to the React Native dependencies ( Lines 246 to 253 in 9827fcb
NOTE: This solution is a temporary workaround until we upgrade the React Native and Jest versions. |
@fluiddot Thanks for this issue and the work you put in already, I think it's very important to address this. I have no experience with upgrading Node in a project like this, but will follow this to learn about it and think along where I can. As there's not much time left before the end of April, is there a way we can give this a higher priority? Should it be added to a particular milestone? And if we're not able to figure this out and merge it before the EOL, what are the risks of being late? Will things break, are there security implications or will it "just" not receive support anymore? |
@fluiddot, thank you for opening this issue and collecting related efforts to synchronize work. I updated the description and included a reference to a related PR in WordPress core: WordPress/wordpress-develop#4028. After April 30th, once Gutenberg runs with NodeJS 18 and npm 9, we will need to follow up with upgrading the minimum required version to Node 16.0.0 and npm 7.10.0 that ships with it. @gvgvgvijayan made me realize that after opening #48368 last week. We will have to update |
I'm thinking about a potential plan in order to move the upgrade forward: 1. Fix the current dependency conflictsFollowing the approach mentioned in this comment, we could fix the current dependency conflicts related to React native ( ℹ️ I can work on this and have a PR ready today/tomorrow. 2. Decide the target version of
|
An excellent action plan, @fluiddot. I don't have strong opinions about npm version. We enforce the maximum version of Node and npm so increasing that to |
Thanks for working on this all! I haven't taken a deep dive into the challenges on the Gutenberg side yet, but I have on the Core side in Trac-56658 (the updates in both locations will need to be coordinated to happen relatively at the same time). For the related Core changes, see WordPress/wordpress-develop#4028. It's my strong preference to upgrade to the latest Node and npm versions in one change instead of a two step process if possible. Each time we change the version requirements for these tools, we have to communicate it to contributors so that everyone can make any needed adjustments to their workflows. I know Another thing to keep in mind is that 7.x of npm upgrade the lock file format. When we update to |
For visibility, @kevin940726 opened PR #48950 that upgrades Node to v18 and npm to v9. It contains more changes the discussed above, like:
|
Now that #47388 is merged, I updated the PR's description to reflect that the issue with |
This is a workaround for this issue related to dependencies - WordPress/gutenberg#48588
This should be partially resolved now with #53426, putting Gutenberg on Node 16 and NPM 8. Legacy peer dep mode is still enabled until we can fix the remaining issues! More here: https://make.wordpress.org/core/2023/08/09/updating-wordpress-to-use-more-modern-versions-of-node-js-npm/ |
We still need to pick more changes prepared by @kevin940726 ing #48950:
There might be more work ready to land in the branch 😄 Finally, we should remove the |
Based on the In relation to this, upgrading to |
@fluiddot, can you also comment here https://make.wordpress.org/systems/2023/02/09/upgrade-nodejs-npm-on-the-build-server/ about EOL for Node 16? |
Node 18 is now supported. Ticket and PR for core to go to Node 18: |
By the way, Node 20 is now the current active LTS. @fluiddot, should we reach out to systems, try to get on v20, and skip v18 in the meantime? |
Worth reaching out, but I'm skeptical about the timeline for that. GitHub Actions is also skipping Node 18 and going straight to Node 20, see https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/ If we could do that as well, it would mean having to maintain fewer Node versions across all branches. On the other hand, the JS ecosystem isn't usually fast to catch up, so not sure how easy the migration would be for Node 20. |
I don't think Node 20 is supposed to have many breaking changes, though I suppose it's worth trying in a branch! |
Draft here, just to see what failures come up: #55561 |
Looks like CI is passing, so I think on the Gutenberg side, this will be an easy update. I'm not familiar with the core WP side though |
Hey @noahtallen 👋. Good point, following this documentation, In this regard, I'd like to note that the issues we had in the past have been related to upgrading In any case, I'd lean toward choosing the easiest and quicker approach, either using version 18 or 20, as we still use
Sure, we could reach out to systems to notify them about using |
I agree. It's unlikely we will get this support added on the build server this calendar year. But we can still make a request. If there are specific features in 20.x that could be utilized, we could build a more compelling case for it to be made available.
Just noting that this only really applies to actions such as actions/checkout, though. actions/setup-node still supports any version of Node/npm. Good to look at what others are doing (and skipping 18 is also my preference), but it's not technically a restriction for our decision here. 18.x will also be in LTS maintenance mode for 18 months. There is a longer term security being on 18.x. 16.x was a bit of a unicorn because the EOL date was moved up by 7 months, and we were also on 14.x for a really long time.
I think the issue that we may encounter will be dependencies having an upper limit to the version they allow similar to how we do. I think it's worth exploring so we know what the challenges will be, but there may be a bit of a waiting game for packages to update. I'd also like to see us get to a state where we can remove With the WordPress 6.4 release coming out on November 7th, let's hold off on this until after that when contributors will have more time. I plan to circle back to this the following week and we can coordinate updating Core SVN and Gutenberg at the same time. |
In my PR above, I did update to npm 10 at the same time, and everything appears to be working correctly in CI. I'd love to remove legacy peer does too, but I don't think it makes a big difference which Node/npm version we're on when we do that. By the way, do we know why it takes so long to make another Node binary available on the build servers? |
I opened a wordpress-develop PR to test Node 20 and npm 10 for core: WordPress/wordpress-develop#5571 |
I don't think I have access to create posts on https://make.wordpress.org/systems/. Could someone else create the request so that we could at get the process started? |
I don't have permission either to create posts there. @desrosj since you are the author of the post Upgrade NodeJS/npm on the Build Server, I wonder if you could help us with this. Thanks 🙇 ! |
I couldn't find an open PR that stages updating to Node.js 18.x, so I've gone and made one: #56331. I also updated WordPress/wordpress-develop#5515. One thing that's different than the usual approach is that I removed the upper limit to the versions that can be used. In my testing, there are no problems when using 20.x. Even if we can't use 20.x as the version used to build the final software, I think it's reasonable to allow use of it and test against it as long as the results are the same. For example, recently the format of the Happy to post again on the systems blog as well. But I'd like to have a better reasoning than "please install the latest version" because that will put the request into their backlog instead of at the forefront. |
I think the main reason to update is because Node version 16 is now at end of life. I'm not sure exactly what it means, but I assume no more bug (and maybe even security) fixes Node 20 is the current LTS, and I think it should be any project's priority to remain on the current, stable, supported versions of software. We also technically don't want the latest version (21), just the current LTS, which is Node 20. ;) I didn't realize that Node 18 was already available on that build server; that makes things easier for us! :) However, I'm not sure there will ever be a more urgent reason, until Node 18 reaches EoL in 2025. I feel like this shouldn't be an ad-hoc process -- we should just be in the habit of updating to the current LTS as it becomes active each year. It often becomes more work the longer you wait. So maybe it'd still be worth creating the request, because we don't want it to suddenly become urgent at the last minute a year down the road. I guess the other approach is just doing it at the last minute when it becomes a security issue (e.g. Node 14 and now Node 16). The other thing on my mind is that if we could just skip Node 18 and go to 20 right away, that makes developer's lives slightly easier :) Just my opinion about it! |
I second what @noahtallen says and would argue staying on top of the current LTS version of Node.js is what we should aim for. |
Thanks for all the work folks! The changes have been merged to both Gutenberg and WordPress Core, and I've gone and published an announcement: https://make.wordpress.org/core/2023/12/20/updating-wordpress-to-use-more-modern-versions-of-node-js-npm-2/. See you all in April for 22.x 😉 |
Intro
The purpose of this issue is to serve as the source of truth for the topic related to upgrading the
node
andnpm
versions, as well as be the central point for discussing how to move it forward.See also a related PR in WordPress core: WordPress/wordpress-develop#4028.
Context
Currently, Gutenberg allows the following versions:
node
14+ (>=14.0.0
)npm
6 (>=6.9.0 <7
)The problem is that the recommended
node
version is in maintenance and the End-of-life is April, 30th, 2023, so it would be great to upgrade it. However, newnode
versions usenpm
versions above 6, which are currently blocked due to issues with dependencies (see below under theBlockers
section).Goal
Upgrade to the latest LTS version of
node
:node
18.14.2npm
9.5.0Or alternatively, if we find blockers using
npm
9, upgrade to the latest LTS version that supportsnpm
8:node
18.13.0npm
8.19.3NOTE: End-of-life of
node
18 is 2025-04-30.Blockers
The main blockers at this point are related to dependencies/peer dependencies, in the following sections are described:
1.
@testing-library/react-native
dependency ✅Error logs
jest@">=28.0.0"
jest@27.4.5
🔧 How to solve it:
There's an ongoing effort to upgrade Jest version to 29 in #47388, so we can either downgrade the dependency.@testing-library/react-native
to a previous version (10.1.1
) or wait to the PR to be mergedUPDATE: ✅ This issue has been solved with #47388.
2.
react-native
dependency ❌Error logs
react@"18.0.0"
react@18.2.0
🔧 How to solve it: The optimal approach for this would be to upgrade React Native to version
0.71.0
. However, in the meantime, we could override the dependency as a workaround.3. Other warnings related to peer dependencies⚠️
Warning logs
🔧 How to solve it: It's likely that these warnings won't block using
npm
8 but it would be interesting to address them in the future, especially for usingnpm
9.Affected dependencies:
@mdx-js/react
ajv-keywords
react-element-to-jsx-string
react-inspector
webpack-filter-warnings-plugin
Related opened issues/PRs
npm install
with npm 7 and higher #46652NOTE: Please feel free to edit the above with issues/PRs related to this topic.
The text was updated successfully, but these errors were encountered: