Make WordPress Core

Opened 3 months ago

Last modified 3 hours ago

#64618 assigned defect (bug)

Playground Node.js engine requirement broke Core WP builds

Reported by: bpayton's profile bpayton Owned by: youknowriad's profile youknowriad
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: close
Focuses: Cc:

Description (last modified by bpayton)

WordPress Core builds broke recently due to a mismatch between the Node.js versions supported by WordPress Core and WordPress Playround.

This was reported by @barry in Slack, and there is a workaround in place to avoid the breakage.

Core declares compatibility with Node.js 20.10.0 and above while Playground declares compatibility with Node.js 22.12.0 and above.

After grepping the WordPress and Gutenberg sources for "playground", the only Playground dependency I could find in Core or Gutenberg is by wp-env. If that is indeed the only dependency, then this conflict appears to occur due to a wp-env dependency on Playground CLI.

Change History (13)

#1 @bpayton
3 months ago

@youknowriad, it would be great if Playground did not have to coordinate Node.js version compatibility with Core, but I'm not sure if that is reasonable to avoid.

Given that wp-env uses npx to launch Playground CLI, we could technically remove the declared dependency from the wp-env package.json to avoid engine version conflicts based on package.json. But wp-env users on Node.js 20.x won't be able to use the Playground mode unless they upgrade to a Playground-compatible Node.js version.

It's technically possible that Playground could fall behind Core's required Node.js version, but it seems unlikely because Playground is constantly needing to leverage bleeding-edge JS runtime features.

Do you have any thoughts on what the best course would be?

cc @zieladam for visiblity

Last edited 3 months ago by bpayton (previous) (diff)

#2 @bpayton
3 months ago

  • Description modified (diff)

#3 @bpayton
3 months ago

  • Description modified (diff)

#4 @bpayton
3 months ago

  • Description modified (diff)

#5 follow-up: @youknowriad
3 months ago

Thanks for the ping, IMO wp-env and playground-cli are too close together to be using different node versions, so I think it's actually legit to have to coordinate.

I feel like instead of fighting this we should instead ensure that these low level tools support a higher ranger of Node versions.

That said, I know in Gutenberg and Core, there were recent discussions about upgrading minimal Node.JS version. @jsnajdr or @desrosj might know what's the status there.

#6 @zieladam
3 months ago

Coordination sounds good. I also wonder if it would make sense to add a CI check to Playground CLI such as "Gutenberg trunk builds". Although we'd likely see some false positives when there are legit failures in Gutenberg trunk. Maybe, then, "The required Node.js version is the same".

Playground could potentially revert back to Node.js 20, too. @fellyph @berislavgrgicak @wojtekn what was the technical motivation for upgrading to Node 22?

#7 @fellyph
3 months ago

Hi @zieladam,

Updating to node 22, we would be able to update some packages on Playground and the playground extension [build was failing](https://github.com/WordPress/wordpress-playground/pull/3110) because the package @vitejs/plugin-react needed the node version 22, and Electron support for node 22 allowed Studio to have some performance improvements.

#8 @wojtekn
3 months ago

I'm unsure what the motivation was for the recent change.

Besides that, is it correct to say Playground is compatible with Node 20 if there are features like dynamic extensions (and JSPI) that require a much newer version, like 24?

#9 @berislav.grgicak
3 months ago

Besides that, is it correct to say Playground is compatible with Node 20 if there are features like dynamic extensions (and JSPI) that require a much newer version, like 24?

Correct, some Playground features will only work on newer Node versions, but Playground is Node 20 compatible.

#10 @berislav.grgicak
3 months ago

From now on, I think that staying on the same Node version as Core is a good move and that we should downgrade Playground's Node version to match Core.

As @bpayton mentioned, Playground benefits from newer versions of Node, and it's in our interest to upgrade. At the same time, we don't want to prevent projects from updating to the latest Playground version just because we increased the minimum Node version.

Before every Node version update, we usually check with projects like Studio if they already use the newer Node version and wait for the upgrade if they don't.

Until recently, Core didn't use Playground, so we didn't consider maintaining support for Core's Node version.

To avoid issues like this in the future, we could add a simple CI check that ensures Playground's Node version matches or is below Core's Node version.

When it comes to Playground features like JSPI, we can document that its support depends on a newer Node version.

#11 @audrasjb
12 hours ago

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

#12 @audrasjb
12 hours ago

  • Version trunk deleted

#13 in reply to: ↑ 5 @desrosj
3 hours ago

  • Keywords close added

I believe that after [61873] (which removed the requirement to checkout and build the gutenberg repository as a part of the build script for this one) this will no longer be a problem.

That said, I know in Gutenberg and Core, there were recent discussions about upgrading minimal Node.JS version. @jsnajdr or @desrosj might know what's the status there.

Just connecting conversations. This issue in the Gutenberg repository is discussing and planning around updating Node.js to 24.x in wordpress-develop and gutenberg.

There's a new page in the Core Handbook documenting the process to upgrade the version of Node.js/npm used. I think it would be helpful to add a section about coordinating with the other projects across the WordPress org, like Playground.

Adding a close suggestion pending confirmation that [61873] resolves the problem.

Note: See TracTickets for help on using tickets.