Playground Node.js engine requirement broke Core WP builds

[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.

[bpayton]

@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

[youknowriad]

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.

[zieladam]

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?

[fellyph]

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.

[wojtekn]

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?

[berislav.grgicak]

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.

[berislav.grgicak]

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.