@adamziel How do I test the built version?

Here's what I tried:

$ npm run build
$ node /Users/danielbachhuber/projects/wordpress-playground/dist/packages/wp-now/main.js
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '/Users/danielbachhuber/projects/wordpress-playground/node_modules/@php-wasm/node/' imported from /Users/danielbachhuber/projects/wordpress-playground/dist/packages/wp-now/main.js

@adamziel How do I test the built version?

nx preview wp-now should work.

But wait:

• Could this use the engines feature of package.json instead of adding a custom condition?
• Let's find a way of addressing this in all the packages and not just wp-now. The engines entry could perhaps do it with little effort.

nx preview wp-now should work.

@adamziel Er, but then I'd be using nx, etc. etc. I want to test wp-now as though an end user has installed it.

Could this use the engines feature of package.json instead of adding a custom condition?

ChatGPT says it's not quite the same effect:

Let's find a way of addressing this in all the packages and not just wp-now. The engines entry could perhaps do it with little effort.

Are other packages run at the command line? How would we test this?

Er, but then I'd be using nx, etc. etc. I want to test wp-now as though an end user has installed it.

Ah, I see. That's going to be tough in the current setup. It needs to import dependencies that don't live in node_modules and nx sets up a custom loader to enable that. Here's a different idea: build wp-now, the binary, as a single bundle and avoid importing things at all.

ChatGPT says it's not quite the same effect

It doesn't have the same effect but it is the standard way of solving this problem for a developer working with the repository clone.

The problem with checking node version is that it won't work if you run wp-now outside of Node. Like in Deno, or in the VS Code extension, or (probably) in Stackblitz.

As for someone including wp-now in their project dependencies, that sounds like a node problem, not wp-now problem. The issue is with a missing Event class – maybe they shimmed that? Why prevent them from using a package they were able to install?

Are other packages run at the command line? How would we test this?

It's php-wasm/cli. I'm a bit confused, though – is this a bundling issue or a runtime issue? I thought the build command failed.

I'm a bit confused, though – is this a bundling issue or a runtime issue? I thought the build command failed.

This is fixing the issue identified in WordPress/playground-tools#11, which originated from npm install -g @wp-now/wp-now.

Here's a different idea: build wp-now, the binary, as a single bundle and avoid importing things at all.

This seems like a separate issue...

It doesn't have the same effect but it is the standard way of solving this problem for a developer working with the repository clone.

Maybe we should do both?

This is fixing the issue identified in WordPress/playground-tools#11, which originated from npm install -g @wp-now/wp-now.

Thanks for clarifying! From the stack trace, that's a @php-wasm/node issue. I don't want to throw an error in there, though. You can do that in wp-now, just keep in mind that will prevent non-node runtimes from using wp-now.

This seems like a separate issue...

It is a separate issue. I'm just answering the question of how to run it like a npm install -g user would. This repository isn't structured in a way that allows you to do that at the moment.

Maybe we should do both?

I wouldn't – Node is just one way of running JavaScript. Logging a warning without exiting could be a good middle-ground here.

Per our conversation, we'll add engines in a follow-up PR.