Skip to content

build(pnpm): resolve pnpm from devEngines, align engines with the policy - #339

Merged
KaiSchwarz-cnic merged 1 commit into
masterfrom
RSRMID-3008/node-toolchain-policy
Aug 28, 2026
Merged

build(pnpm): resolve pnpm from devEngines, align engines with the policy#339
KaiSchwarz-cnic merged 1 commit into
masterfrom
RSRMID-3008/node-toolchain-policy

Conversation

@KaiSchwarz-cnic

@KaiSchwarz-cnic KaiSchwarz-cnic commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Part of the Node/npm/pnpm toolchain alignment in RSRMID-3008.

engines.node and engines.npm now match .github/node-policy.conf in
rtldev-middleware-workspace, and the pnpm version is declared once, as a range, in
devEngines.packageManager.

devEngines validates instead of switching: a pnpm outside the range fails the command
by name, where packageManager made pnpm silently download and re-execute itself as one
exact version. Declaring it also makes pnpm lock itself — the packageManagerDependencies
document in pnpm-lock.yaml is that resolution, and pnpm i --frozen-lockfile fails
until it is committed, which is why the lockfile moves here too. The lockfile diff is
purely that document; no resolved dependency version changes.

The caller workflows pass pnpm-version: "" so pnpm/action-setup resolves the version
from this manifest rather than installing whatever pnpm is newest.

Merge order

This one is independent — it can merge as soon as CI is green. The
rtldev-middleware-shareable-workflows PR in this set must merge after every
manifest PR, because it inverts the pnpm-version default.

engines.node and engines.npm now match .github/node-policy.conf in
rtldev-middleware-workspace, and the pnpm version is declared once, as a range, in
devEngines.packageManager rather than left to whatever pnpm CI installed last.

devEngines validates instead of switching: a pnpm outside the range fails the command
by name, where packageManager made pnpm silently download and re-execute itself as one
exact version. Declaring it also makes pnpm lock itself — the packageManagerDependencies
document in pnpm-lock.yaml is that resolution, and pnpm i --frozen-lockfile fails until
it is committed, which is why the lockfile moves in this commit too.

The caller workflows pass pnpm-version: "" so pnpm/action-setup resolves the version
from this manifest rather than installing whatever pnpm is newest.

RSRMID-3008
@KaiSchwarz-cnic
KaiSchwarz-cnic merged commit 0fc43bc into master Aug 28, 2026
2 of 7 checks passed
@KaiSchwarz-cnic
KaiSchwarz-cnic deleted the RSRMID-3008/node-toolchain-policy branch August 28, 2026 19:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant