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

Start with the publish flow in PublishUtilities and PublishAction, using the listed sites in @microsoft/rush-lib/dist/commons.js as a map: changed-project filtering, version-bump guards, dependency propagation, registry lookup, and changefile updates. Reproduce with Rush 5.163.0 or 5.172.1 and a small version-policy project graph. Done means prerelease versioning is scoped by the selected policy while publication eligibility and unnecessary npm view requests remain separate.

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

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