Skip to content

[rush] Allow prerelease versioning to be scoped by version policy, independently of shouldPublish #5960

Description

@PrzemyslawMikos

Summary

We use rush publish --apply --prerelease-name <name> --ignore-git-hooks in CI feature mode to stamp a prerelease version onto product packages that were changed, or that are runtime consumers of a changed package. We do not want to publish those dependency packages.

The problem is that Rush (internally) uses shouldPublish as a eligibility signal for two different concerns:

  1. Versioning — which projects get their version bumped, and which projects receive dependency-driven bumps.
  2. NPM publication — which projects may be published to a registry, and which projects get a registry existence check.

The projects we need versioned are our product packages, which in rush.json config have publishPolicy set. Command rush publish --apply --prerelease-name "${PRERELEASE_NAME}" --ignore-git-hooks bumps their versions but additionally it applies versions for all other packages that are not marked by same publish policy or have shouldPublish option set to false, this causes many (around 300 in our case) requests to our store npm view <package> which takes additional unnececery time.

We would like an option to say: bump versions for the projects in version policy X (including dependency propagation), do not treat that as publish eligibility for dependency packages.

Details

What we are trying to accomplish

internal-package-changed			(internal library, must NOT be published - no `npm view` lookup expected)
  -> application-package			(runtime consumer of `internal-package-changed` and its version becomes 1.2.3-feature-name.123 - should be published according to policy)

What we tried, and why each option falls short

Command / parameter Outcome
rush publish --apply --prerelease-name NAME --partial-prerelease Correct changefile processing and dependency propagation, but skips shouldPublish: false packages and still queries the registry.
--version-policy <policy> Only takes effect together with --include-all.
--include-all Switches to the publish-all path, which does not process changefiles and ignores prerelease / partial-prerelease semantics.
Set shouldPublish: false on the packages npm view <package> requests are still performed

So there is currently no combination that yields policy-scoped prerelease versioning with dependency impact while leaving publication eligibility untouched.

Where the coupling lives

To unblock our pipeline we temporarily patch the installed Rush bundle
(@microsoft/rush-lib/dist/commons.js) during the feature build and revert it immediately afterwards. The patch replaces shouldPublish checks with versionPolicyName === <policy> checks at these sites (upstream equivalents appear to be in PublishUtilities and PublishAction):

  • the changed-project filter — ... || !project.shouldPublish
  • the per-change bump guard — const shouldSkipVersionBump = !project.shouldPublish || ...
  • the dependency propagation guard — if (!depProject.shouldPublish || ...)
  • the registry lookup — if (!(await this._packageExistsAsync(project))), so that the npm view call is only made for projects inside the selected policy
  • two projectsByName.get(...).shouldPublish guards used while updating changefiles / dependent versions

Suggested direction

Any of the following would remove the need for our patch:

  • Make --version-policy meaningful for rush publish --apply (not only with --include-all), and treat membership in the selected policy — rather than shouldPublish — as the versioning eligibility signal for that run.
  • Or add an explicit project-level setting (for example, a shouldVersion / versionOnly concept, or a version-policy option) that prevents from version bump therefore attempt to publish.
  • And skip the package-existence lookup for projects that are not going to be published, so that --apply without --publish does not require registry access.

Notes

  • Reproduced on Rush 5.163.0 and 5.172.1 — the relevant code sites are identical in both.
  • We can put together a minimal public repro repository (two projects, one version policy, shouldPublish: false, one changefile) if that would help.

Standard questions

Question Answer
@microsoft/rush globally installed version? n/a — CI doesn't use global install
rushVersion from rush.json? 5.163.0 and 5.172.1
pnpmVersion, npmVersion, or yarnVersion from rush.json? pnpm@10.33.0
pnpm useWorkspaces Set to true
Operating system? Linux (CI) / Windows (local)
Would you consider contributing a PR? Yes
Node.js version (node -v)? 24.x

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Needs triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions