Support --wp=nightly and --wp=trunk when starting wp-now

[danielbachhuber]

Fixes #158

What?

Adds support for --wp=nightly and --wp=trunk when starting wp-now.

How?

Returns 'https://wordpress.org/nightly-builds/wordpress-latest.zip' from getWordPressVersionUrl() when version === 'trunk' || version === 'nightly'.

Testing Instructions

1. Run nx preview wp-now start --path=/Users/danielbachhuber/Desktop --wp=trunk and verify the latest nightly build is used to launch wp-now.

[danielbachhuber]

I'm getting http://localhost:8881/wp-admin/install.php when --wp=nightly is used, and then I end up with this error:

[sejas]

Looks good 👍
I wonder if using only one value like trunk would be enough.

I confirm a new folder trunk was downloaded after running:

• nvm use && npm install && npx nx build wp-now
• node dist/packages/wp-now/cli.js start --wp=nightly

@danielbachhuber , currently the versions are not auto-updated, the second time you will run wp-now start --wp=trunk, the folder will exist and the "outdated" version will be executed. Is that expected?

For common versions that is the normal behaviour, but I guess for trunk a user would expect downloading a new version each time it has changed.

[swissspidy]

Note that nightly and trunk are semantically different. Given that only the former is available as a prebuilt package, it might be easier to support only nightly.

[danielbachhuber]

then I end up with this error:

As it turns out, I had an outdated version of the SQLite integration:

I guess we need something else for that.

Note that nightly and trunk are semantically different. Given that only the former is available as a prebuilt package, it might be easier to support only nightly.

@swissspidy WP-CLI treats them as the same:

https://github.com/wp-cli/core-command/blob/dcac4c36a3c596f1c81779bdbaa0c5f508f14075/src/Core_Command.php#L191-L193

currently the versions are not auto-updated, the second time you will run wp-now start --wp=trunk, the folder will exist and the "outdated" version will be executed. Is that expected?

For common versions that is the normal behaviour, but I guess for trunk a user would expect downloading a new version each time it has changed.

@sejas I think it's the expected behavior, but I don't have a strong opinion about it.

Notably, I don't want it automatically deleting files if I don't have a network connection.

[sejas]

@sejas I think it's the expected behavior, but I don't have a strong opinion about it.
Notably, I don't want it automatically deleting files if I don't have a network connection.

We can always improve it further in next PRs.
Maybe a --force download flag, or ideally checking the checksum/sha of the zip before downloading it.

[swissspidy]

@danielbachhuber Perhaps we could reconsider? trunk could imply using https://github.com/WordPress/WordPress/archive/refs/heads/master.zip

[danielbachhuber]

@swissspidy Personally, I think it should follow the behavior of WP-CLI. What's your argument for having different behavior?