Blueprints and Client: update engine to node v20 on package.json

[sejas]

What is this PR doing?

Update the node version required for:

• @wp-playground/blueprints
• @wp-playground/client

What problem is it solving?

• As we found out in Blueprints: add support for NodeJS #576 (comment), and wp-now: execute blueprint steps given a file path playground-tools#82, there are some JS classes such as CustomEvent and File that are implemented in node v20.

How is the problem addressed?

Update the node version defined in package.json > engine

Testing Instructions

• Build and tests pass

[dmsnell]

@sejas should we bump the version for all packages and also in the top-level package.json?

I'm just wondering if there's any benefit to having different minimum versions in the different packages

[danielbachhuber]

there are some JS classes such as CustomEvent and File that are implemented in node v20.

Would it be possible to shim these classes so we can keep node 16/18 support? If node 18 is LTS, I'm concerned that we'll lose some number of users by requiring node 20. It might break the VS Code Extension too.

[sejas]

@sejas should we bump the version for all packages and also in the top-level package.json?

I'm just wondering if there's any benefit to having different minimum versions in the different packages

@dmsnell, the benefit would be that the rest of the packages will work in third party apps with lower node versions.

@adamziel asked to upgrade just those packages.

would you please open a PR to bump Node to 20 in the engines section of package.json for +@wp-playground/blueprintsand@wp-playground/client`?

Maybe I understood it too literally. I have doubts if that engine section will be overwritten in the next release.

[sejas]

there are some JS classes such as CustomEvent and File that are implemented in node v20.

Would it be possible to shim these classes so we can keep node 16/18 support? If node 18 is LTS, I'm concerned that we'll lose some number of users by requiring node 20. It might break the VS Code Extension too.

@danielbachhuber, Yes, it's possible.

• Actually, in my first approach I was creating dummy polyfills https://github.com/WordPress/wordpress-playground/pull/576/files

I took this approach since @adamziel suggested it over writing polyfills.

@sejas would bumping the minimal required Node.js version to 20 solve it without the polyfills? Are there any blockers for that?

The File implementation is empty, so we will need a second PR to make the steps to install themes and plugins work.
If node 20 is a no-go for any reason then let's bring the File polyfill into this PR so we can see if anything else breaks

This week, I can estimate the level of effort to pull the NodeJS code and support lower versions. And we can decide if it's worth it or not. Sounds good?

[danielbachhuber]

This week, I can estimate the level of effort to pull the NodeJS code and support lower versions. And we can decide if it's worth it or not. Sounds good?

@sejas Sure, that's fine.

[dmsnell]

This is pure personal preference, but I'm fairly okay with aggressively updating the minimum version and even more so of pinning all the versions together. It could be nice indicating a given package doesn't rely on a certain version, but then once people use the packages together they would need to update anyway.

Also if we can avoid polyfills by bumping the minimum version then that's code we don't have to write and schedule to remove later when it's no longer needed because of some actual version requirement bump.

This is still a fairly new and rapid project. We can make some more pressing demands on versions, plus if someone really wants to they can still run it in old versions, but at their own risk.

The version information in engines is nice to know but it doesn't block execution (which is actually unfortunate IMO but it is what it is).

[danielbachhuber]

This is pure personal preference, but I'm fairly okay with aggressively updating the minimum version and even more so of pinning all the versions together. It could be nice indicating a given package doesn't rely on a certain version, but then once people use the packages together they would need to update anyway.

@dmsnell I think this is at odds with "most users" being able to use wp-now:

See some conversation in WordPress/playground-tools#83.

I think we should support LTS as a minimum if we care about other users being able to use both WordPress Playground and wp-now with their projects.

[dmsnell]

@danielbachhuber that's fine, which is why I added the caveat stating my personal preference.

there are two issues in the quoted comment though: minimum version and harmonizing the versions. for the sake of integrations there is still potential value in making all packages require the same base version. it's obviously not a problem to specify separate ones, but it's still a tradeoff I think we are free to consider.

[eliot-akira]

Found out that the current version of VS Code bundles Node.js 16.17.1. I saw this information by chance, by going to Help -> About.

It's a somewhat old version that comes bundled with Electron, which lags behind until its Node.js runtime is merged from upstream. Currently, VS Code bundles Electron 22. Even the newest version of Electron 25 bundles Node.js 18.15.0, and I imagine it will take time until VS Code upgrades to that version.

https://releases.electronjs.org/

That means, as @danielbachhuber suggested earlier, the VS Code extension for the Playground needs to support Node.js 16/18 for the foreseeable future.

As far as we know, the only thing necessary to meet that requirement is to polyfill the CustomEvent class (available from Node 19) and File class (from Node 20) in the Blueprint package - which was partially started in PR #576.

[danielbachhuber]

Oh yeah, I forgot about the VS Code Extension. @dmsnell and I didn't factor it into our conversation yesterday, whoops. Thanks for mentioning!

[dmsnell]

Sounds good; let's just polyfill then. Thanks for noticing that @eliot-akira

[sejas]

• Closing this PR in favor of future development of polyfills similar to Blueprints: add support for NodeJS #576