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:
- Versioning — which projects get their version bumped, and which projects receive dependency-driven bumps.
- 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 |
Summary
We use
rush publish --apply --prerelease-name <name> --ignore-git-hooksin 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
shouldPublishas a eligibility signal for two different concerns: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-hooksbumps their versions but additionally it applies versions for all other packages that are not marked by same publish policy or haveshouldPublishoption set tofalse, this causes many (around 300 in our case) requests to our storenpm 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
What we tried, and why each option falls short
rush publish --apply --prerelease-name NAME --partial-prereleaseshouldPublish: falsepackages and still queries the registry.--version-policy <policy>--include-all.--include-allshouldPublish: falseon the packagesnpm view <package>requests are still performedSo 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 replacesshouldPublishchecks withversionPolicyName === <policy>checks at these sites (upstream equivalents appear to be inPublishUtilitiesandPublishAction):... || !project.shouldPublishconst shouldSkipVersionBump = !project.shouldPublish || ...if (!depProject.shouldPublish || ...)if (!(await this._packageExistsAsync(project))), so that thenpm viewcall is only made for projects inside the selected policyprojectsByName.get(...).shouldPublishguards used while updating changefiles / dependent versionsSuggested direction
Any of the following would remove the need for our patch:
--version-policymeaningful forrush publish --apply(not only with--include-all), and treat membership in the selected policy — rather thanshouldPublish— as the versioning eligibility signal for that run.shouldVersion/versionOnlyconcept, or a version-policy option) that prevents from version bump therefore attempt to publish.--applywithout--publishdoes not require registry access.Notes
shouldPublish: false, one changefile) if that would help.Standard questions
@microsoft/rushglobally installed version?rushVersionfrom rush.json?pnpmVersion,npmVersion, oryarnVersionfrom rush.json?useWorkspacestruenode -v)?