Consistent phpunit runners for local and CI

[kasparsd]

Fixes #479, fixes #383.

A follow-up to #382.

Development workflow consistency:

• Standardizes local development and CI around wp-env so both paths use the same environment bootstrapping and runtime logic.
• Adds a small npm command layer for common tasks like CLI access, linting, formatting, PHPUnit, and coverage, so developers and CI invoke the same commands.
• Updates the coding standards workflow to run through the wp-env-based toolchain instead of relying on a separate runner-level PHP setup.

Local setup and onboarding:

• Commits a Node version via .nvmrc and upgrades @wordpress/env, reducing local setup drift and keeping machines closer to CI.
• Expands the contributing docs to make wp-env the default local workflow, covering start/log/stop commands, PHPUnit usage, coverage, and version overrides.
• Supports both .wp-env.override.json and WP_ENV_PHP_VERSION / WP_ENV_CORE env vars, making local environment customization straightforward without changing repo defaults.

Local PHPUnit execution:

• Moves PHPUnit execution into the wp-env tests container, removing the old split between custom local setup and CI-only test installation.
• Adds a dedicated tests:cli path and install flow for test dependencies, so local test runs are easier to reason about and reuse.
• Aligns the single-site and multisite PHPUnit config files with this workflow, including cleaner cache and coverage paths.

WordPress and PHP version matrix support:

• Makes it possible to run PHPUnit locally against different WordPress core and PHP combinations by driving wp-env from override files or environment variables.
• Broadens Composer dev tooling to support multiple PHPUnit versions and include the WP-CLI bundle needed for this workflow.
• Replaces the hardcoded GitHub Actions exclusion list with a generated PHP/WordPress compatibility matrix, centralizing supported combinations in one script.

CI parity with local testing:

• Uses the generated matrix in GitHub Actions so each job boots the requested WordPress and PHP combination the same way it can be done locally.
• Refreshes Composer dependencies per matrix job so the right PHPUnit version is installed for that exact WordPress/PHP pairing.
• Extends the same wp-env-based approach to coverage runs, improving parity between local verification and CI.

CI timing

Previously the phpunit setup in CI didn't use wp-env leading to two different ways of running the same tests. Switching to wp-env ensures that we can run the tests with any combination of PHP and WP core both locally and during CI.

Running the phpunit test matrix in CI before the change took 1min 42s:

while now it takes 3min 16s (or 2min 30s in recent runs):

which is a minor increase but offers consistency and predictability.

[github-actions]

🧪 Test this PR on Playground

[kasparsd]

Introduce .nvmrc to lock the version of Node to a known version for this project.

[kasparsd]

Use a simple node script to generate the test matrix since it is easier to read and maintain.

[kasparsd]

Add in coverage reporting.

[kasparsd]

Fix a few remaining phpstan errors.

[kasparsd]

Lock everything to the versions supported by the min-supported PHP of the project (8.0). During CI we delete the lock file and update the requirements to work with the relevant versions of PHP.

[kasparsd]

Composer is smart enough to try the local vendor/bin binaries before using globals so we make this consistent with how phpcs and phpstan is called in this file.

[kasparsd]

Add the missing excludes and skip escaping . since it isn't necessary.

[kasparsd]

The trailing /* is also not necessary -- it matches by fragment by default.

[kasparsd]

Ensure phpstan is aware of the wp-cli signatures.

[kasparsd]

Make this consistent with what phpunit.xml.dist was using to cache the results.

[chuckadams]

I personally have less than zero interest in using wp-env as the standard environment: a dependency on node in order to run bash scripts in order to run PHP. If this is the easiest way to switch WP versions quickly in CI, especially if it can cache the different versions, then I'm not going to stand in the way, but I would very much prefer to avoid gratuitous Node dependencies as far as the officially sanctioned dev workflow goes, and would rather see something like DDEV be it instead.

[kasparsd]

if this is the easiest way to switch WP versions quickly in CI, especially if it can cache the different versions

Yeah, this setup (and the updated documentation) allows us to consistently test the plugin against any version of PHP and WP core. Previously the setup used locally (wp-env) was different from what the CI would use, so there was no clear way to replicate failing builds.

I absolutely don't love wp-env but it gets the job done and is a shared convention that others know how to debug and use. The previous mix of bash scripts, system dependencies installed only in CI to run the same tests and linters was arguably more convoluted and harder to maintain.