Conversation
e515207 to
85939a6
Compare
kevin940726
left a comment
There was a problem hiding this comment.
Some workflows are expected to fail in this PR:
- Performance tests
- Compressed size
- Pull request automation
The first two check out to a certain point at trunk which doesn't support later versions of Node.js and npm in the engines settings yet. I don't know how to solve it for this PR, but it should work after merging to trunk though.
Pull request automation also check out to trunk to run the workflow, which doesn't support npm workspaces yet. This issue should also go away after merging to trunk.
| @@ -1,5 +1,5 @@ | |||
| exports.local = { | |||
| host: 'localhost', | |||
| host: '127.0.0.1', | |||
There was a problem hiding this comment.
This seems to be needed after node 17 for some reason.
| moduleDirectories: [ | ||
| '../../node_modules/react-native/Libraries/Utilities', | ||
| '../../node_modules', | ||
| 'node_modules', |
There was a problem hiding this comment.
For some reason the original ../../node_modules doesn't work anymore after opting-in to npm workspaces.
| --> | ||
|
|
||
| ## Unreleased | ||
| - [*] Increase the minimum Node.js version to 18 [#48950] |
There was a problem hiding this comment.
I'm actually not sure if this should be [*] or [***]. Maybe some RN folks could answer that?
There was a problem hiding this comment.
I'd say it's [*] because it's a change that initially won't impact users.
.npmrc
Outdated
There was a problem hiding this comment.
This is supposed to be a temporary solution until we fix all the peer dependency issues.
There was a problem hiding this comment.
@kevin940726 I created a draft PR that solves the peer dependency issue related to React Native and removes this NPM configuration option. As far as I tested, the dependency installation works, although warnings are displayed. Let me know if you'd like to incorporate it into this PR, thanks 🙇 !
There was a problem hiding this comment.
Nice! I tried the same thing too, but I think it would be better to be a separate follow-up PR. Warnings can be intimidating for some, I would like to solve all warnings before we roll them out to all contributors.
|
Just wanted to note that on the Core side, we are blocked by this request to the systems team.. I'll reach out to try and get an update on this today. My preference is to merge this change here, and then merge the accompanying changes to Core right after (same day if possible). But it's not clear if that would require any
Is there any reason why we shouldn't make the minimum v16.x? 14.x is EOL starting April 30th. A secondary goal, IMO, should be to use this as an opportunity to trim all unsupported versions. Is the concern that anyone previously using 12 or 14 pulls updates to Gutenberg or Core and then are unable to run Node scripts? If so, maybe we leave it as 14 in this PR, and include in the post a specific date that we will change the minimum to 16 to allow contributors to update their local environment. |
I would avoid putting immediate pressure on all projects to upgrade to Node 16 because we recommend in the official documents and learning materials using Node 14. Once we update those resources to go with any LTS version, we can switch to Node 16 as the minimum version, or completely remove it from the config of WordPress packages and only leave a note in the corresponding README files. The biggest challenge is the different format for the lock file and more importantly the fact that we still didn't update packages to work correctly with the new behavior for peer dependencies. |
|
We will have to stick with Node.js 16 in WordPress core for now. See https://make.wordpress.org/systems/2023/02/09/upgrade-nodejs-npm-on-the-build-server/#comment-2077 for the context. There shouldn't be a big difference between v16 and v18. @desrosj, do you anticipate any challenges with using two different Node.js versions between both projects? We would still run tests against v16 and v18 on CI in Gutenberg. |
.github/workflows/unit-test.yml
Outdated
| fail-fast: false | ||
| matrix: | ||
| node: ['14'] | ||
| node: ['18'] |
There was a problem hiding this comment.
It would be good to have the same tests running for Node.js v16 and v18. We can change that as a follow-up if that isn't as simple as updating this line.
There was a problem hiding this comment.
The only problem is with the engines setting in the root package.json. It pins both Node and npm to the latest version so that we can ensure developers have the same local environment. However, CI will fail when running Node v16 because we have engine-strict set to true. Perhaps we can ignore this setting on CI with the --engine-strict=false CLI arg? WDYT?
There was a problem hiding this comment.
That would be great to have it possible to run with different Node.js versions whatever the solution is.
There was a problem hiding this comment.
It turns out it might be worth being in a different PR for clarity. Adding cli args to every command is too verbose, we might want to do it another way, like calling npm config set before the test.
There was a problem hiding this comment.
Maybe the GitHub action supports it, see how the registry URL gets passed here:
Follow-up sounds great 👍
There was a problem hiding this comment.
I don't see any useful option in the GitHub action for this tweak:
https://github.com/actions/setup-node/blob/main/action.yml
We will figure out a different approach.
|
This should be ready now! I'll be away for a couple of days, so if anyone can help address any further feedback and merge this will be greatly appreciated! |
|
@kevin940726 @desrosj @gziolo What are the remaining steps for getting this across the line? I notice that April 30th date is approaching 😬 Do we need to update this PR to use node 16 as per this comment? Maybe we can schedule a date to merge this and commit the core patch. |
I thought that's for core, not gutenberg? The only remaining task I see is #48950 (comment), which can be solved in a different PR. LMK if there's something I missed though! Once someone approves the PR I'll rebase it and merge it :) |
It would be great to agree on the date and announce it ahead of time so contributors know when they will have to switch to a different Node.js version when developing for Gutenberg and WordPress core. I think that communication is key here to avoid any disruption, as there are different lock file formats between npm 6, npm 7/8, and npm 9. It's also why we need to enforce a certain pair of Node.js and npm in both projects so people don't get the lock file regenerated with a different lock file version all the time when using different Node.js major versions. I don't know whether we need to use Node.js 16 everywhere, but it definitely might be annoying to have to switch between Node.js 16 and 18 when contributing to both the Gutenberg plugin and WordPress core. Let's keep in mind that the maintenance for Node 16 ends on 2023-09-11 – in 5 months. Regarding the possible date, the next Gutenberg plugin RC1 release will probably happen today, and it will trigger npm publishing. It means that the next tentative windows for upgrading Node.js and npm are:
Technically, we don't need to do everything at once, but it could be easier to schedule all steps for a single week. |
|
Do we have an open PR on core for upgrading Node.js and npm, or is the work ongoing somewhere? Also, curious about the context of why we have to target Node 16 for core for now? |
I think there's one here - WordPress/wordpress-develop#4028 |
The WordPress.org build server that updates https://build.trac.wordpress.org/ when a commit to WordPress is made in SVN does not have Node 18 installed. 16.x is the newest version there. If the If I remember correctly, version requirements defined within As far as I can tell, the differences between 16 and 18 should be minimal. I don't think there is a reason we can't recommend 18 but still support (and test against) 16. We also need to adjust the |
Fair point! I can update it to make the
If I'm not mistaken, |
|
Playwright just dropped support for Node 14 - https://github.com/microsoft/playwright/releases/tag/v1.34.0. |
|
Hey @kevin940726 👋, I noticed it's been a couple of months since the last commit. I'm wondering if we found any blockers that are preventing the PR to continue or if we are just waiting for reviews. Regarding the blockers, and based on the above comments:
NOTE: Regarding React Native, I'd like to share that we're actively working on upgrading it to a version that uses React |
What?
Upgrade Node.js and npm to their latest (LTS) versions.
Related issues and prior art:
nodeandnpmto latest LTS versions #48588npm installwith npm 7 and higher #46652Notable Changes
Start using npm workspaces
Since npm v7, it introduces native support for workspaces to manage monorepo. It works great with
lerna, which is also updated to the latest version in this PR (v6.5.1). We can now run scripts inpackage/folder using the-wcommand. For instance:See the official documentation for more info.
Upgrade lockfile to v3
This is done by an automatic update from the v1 lockfile. I believe that most packages are not changed, which can happen if we delete and regenerate the lockfile from scratch. This should be mostly backward-compatible, but it's still a breaking change, do file an issue if there's any bug!
Deprecate running binaries using
npm binandnode_modules/.binWe should use
npxinstead.npm binis also deprecated in newer npm versions.Enable
legacy-peer-depsThis is mostly a temporary change until we fix all the underlying dependencies issues in the project. See #48588 for more info and the tracking issue.
Update the minimum required version of Node.js and npm in packages.
This is a breaking change. Prior art: #43141.
Why?
Node.js v14 will be EOL at the end of April. Node.js v16 is also going to be EOL in September. See the release schedule. It's a good idea to stay up-to-date and be long-term supported.
How?
Testing Instructions
nvmto upgrade your Node.js version to v18. (nvm install 18)npm i -g npm@latest).npm ci(this will delete thenode_modulesfolder and regenerate it)npm run buildtsc --buildto work, you might have to delete the old cache (rm -rf packages/*/tsconfig.tsbuildinfo).Testing Instructions for Keyboard
Same as above.