Skip to content

Upgrade node to v24 only for CLI#2537

Merged
katinthehatsite merged 7 commits intotrunkfrom
fix/update-npm-in-engines
Feb 6, 2026
Merged

Upgrade node to v24 only for CLI#2537
katinthehatsite merged 7 commits intotrunkfrom
fix/update-npm-in-engines

Conversation

@katinthehatsite
Copy link
Copy Markdown
Contributor

@katinthehatsite katinthehatsite commented Feb 5, 2026

Related issues

Related to: #2486 (comment)

Proposed Changes

This PR ensures that we upgrade node version only for CLI and not for the whole Studio project. Electron is currently using v39.x and is not compatible with Node v24. I explored upgrading Electron so that CLI and the rest of the Studio project could use the same configuration but ran into a blocker with fs-ext. Additionally, according to this comment: #2486 (comment) , it seems that our goal is to untangle with node versions used by CLI and Studio anyway.

Testing Instructions

  • Confirm that in CI, we get the node 22.x installed:
Screenshot 2026-02-05 at 11 17 04 AM

To test CLI node version:

  • Pull the changes from this branch
  • Run nvm use && npm install
  • Run npm run cli:build
  • Run ./bin/node --version
  • Confirm you see node v24.11.0
  • For good measure, confirm that ./bin/node dist/cli/main.js --help works as expected

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?

@katinthehatsite katinthehatsite self-assigned this Feb 5, 2026
@katinthehatsite katinthehatsite marked this pull request as draft February 5, 2026 10:10
archivePath: string,
destDir: string,
binaryName: string
): Promise< void > {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are unrelated linter fixes

}

main();
void main();
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated linter fix

Comment thread .nvmrc
@@ -1 +1 @@
24.11.0
22.20.0
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the changes reverted back from #2486

@katinthehatsite katinthehatsite marked this pull request as ready for review February 5, 2026 10:24
@katinthehatsite katinthehatsite requested review from a team, ivan-ottinger and wojtekn February 5, 2026 10:24
Comment thread .bundled-node-version Outdated
@@ -0,0 +1 @@
24.11.0
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file could be called something else if this is not clear. I also thought about hard-coding it directly into download-node-binary but it could be slightly harder to find that way

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's used only in one place and is not an industry-standard file like .nvmrc, we could hardcode it there. There is no value in creating a new file format for that.

We follow the same approach with the SQLite plugin version.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me, made changes in d9021ad

I also removed the fallback as it should not be needed as the version is always defined.

@wpmobilebot
Copy link
Copy Markdown
Collaborator

wpmobilebot commented Feb 5, 2026

📊 Performance Test Results

Comparing c4b16e6 vs trunk

site-editor

Metric trunk c4b16e6 Diff Change
load 2768.00 ms 2757.00 ms -11.00 ms 🟢 -0.4%

site-startup

Metric trunk c4b16e6 Diff Change
siteCreation 7079.00 ms 7081.00 ms +2.00 ms 🔴 0.0%
siteStartup 3933.00 ms 3930.00 ms -3.00 ms 🟢 -0.1%

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

Comment thread scripts/download-node-binary.ts
Co-authored-by: Wojtek Naruniec <wojtek.naruniec@automattic.com>
Copy link
Copy Markdown
Contributor

@ivan-ottinger ivan-ottinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes, Kat.

Comment thread scripts/download-node-binary.ts Outdated
// This is separate from .nvmrc which controls the development environment and Electron app
const BUNDLED_NODE_VERSION = 'v24.11.0';

function getNodeVersion(): string {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could now get rid of the wrapper getNodeVersion now - since it returns one constant only.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, should be updated 👍

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, Kat! Looks good! 👍🏼

@ivan-ottinger ivan-ottinger self-requested a review February 6, 2026 08:50
@katinthehatsite katinthehatsite merged commit 9c147d4 into trunk Feb 6, 2026
11 checks passed
@katinthehatsite katinthehatsite deleted the fix/update-npm-in-engines branch February 6, 2026 09:16
@fredrikekelund
Copy link
Copy Markdown
Contributor

Connecting the dots between #2486 (comment) and this change…

.nvmrc dictates which node version we use for development, primarily for Studio CLI and potentially (though unlikely, IMO) also for the Electron "back-end logic". It doesn't dictate which node version Electron uses for the "back-end logic" after the app is packaged.

We should not use a different node version for Studio CLI development compared to what we ship in the installer, since we won't be able to catch potential issues related to the node version.

@wojtekn, I'll experiment with the approach we took in #2486 and try to reproduce the error you described in #2486 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants