Context
The @jscutlery/semver peer range currently declares support for a wide span of Nx majors (@nx/devkit ^18 || ^19 || ^20 || ^21 || ^22). However, CI (.github/workflows/test.yml) only runs the test suite against a single pinned Nx version - the one in the workspace devDependencies, which the nx-migrate bot keeps bumped to the latest. So there is currently no signal about whether the older versions in the declared range still work; a regression on, say, Nx 19 would go unnoticed until a user hit it.
Proposal
Add a CI matrix that runs the build and test suite against multiple Nx versions across the supported range, so the declared peer range is actually backed by green tests.
A few things I'd want your input on:
- Is this something you want? (It adds CI time and some setup complexity.)
- Which granularity - every major in the range, or a representative subset (lowest supported / one in the middle / latest)?
- How to structure it, given the workspace pins a single Nx version and the
nx-migrate bot auto-bumps it. Probably a per-matrix-entry install step that overrides the @nx/* packages to the target version before running, rather than a full nx migrate.
Why separate and first
This is independent of any specific version bump and is worth doing on its own. It would also give us real evidence for the follow-up decision on Nx 23 support (drop Nx < 22 vs. stay backward compatible), which I'm raising in a separate issue. I'd land this matrix first and build that change on top.
Context
The
@jscutlery/semverpeer range currently declares support for a wide span of Nx majors (@nx/devkit ^18 || ^19 || ^20 || ^21 || ^22). However, CI (.github/workflows/test.yml) only runs the test suite against a single pinned Nx version - the one in the workspacedevDependencies, which thenx-migratebot keeps bumped to the latest. So there is currently no signal about whether the older versions in the declared range still work; a regression on, say, Nx 19 would go unnoticed until a user hit it.Proposal
Add a CI matrix that runs the build and test suite against multiple Nx versions across the supported range, so the declared peer range is actually backed by green tests.
A few things I'd want your input on:
nx-migratebot auto-bumps it. Probably a per-matrix-entry install step that overrides the@nx/*packages to the target version before running, rather than a fullnx migrate.Why separate and first
This is independent of any specific version bump and is worth doing on its own. It would also give us real evidence for the follow-up decision on Nx 23 support (drop Nx < 22 vs. stay backward compatible), which I'm raising in a separate issue. I'd land this matrix first and build that change on top.