chore(repo): enforce the declared node/pnpm floors at install time - #6351
Draft
os-warren wants to merge 1 commit into
Draft
chore(repo): enforce the declared node/pnpm floors at install time#6351os-warren wants to merge 1 commit into
os-warren wants to merge 1 commit into
Conversation
Add `engine-strict=true` so the root `engines` range stops being advisory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012CZgmFFzqA9cX8tBMhvpFe
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #6264
Adds
engine-strict=trueto.npmrc, so the rootenginesrange corrected by #5306 (node: ">=22.11",pnpm: ">=10") is enforced at install time instead of being documentation.Gate 2 of the card is the work, and everything below is a measurement taken on this branch, not a recollection. All gate results quote the gate's own verdict line; exit codes were captured by redirect before any pipe.
Gate 1 re-verified on my own base
Base
ed859aa35. Rootpackage.jsonreads exactly:Premise holds; root
package.jsonis untouched by this PR. The diff is one file.The measurement that counts: the refusal
A green install proves nothing here —
engine-strictonly changes behaviour outside the range. So the flag was measured by making an environment fail, and by a paired control that isolates the flag as the cause.pnpm install --frozen-lockfile, run against this repository:engine-strictERR_PNPM_UNSUPPORTED_ENGINE—Expected version: >=22.11/Got: v22.4.0WARN Unsupported engine: wanted: {"node":">=22.11"} (current: {"node":"v22.4.0","pnpm":"10.31.0"})ERR_PNPM_UNSUPPORTED_ENGINE—Expected version: >=10/Got: 9.15.9ERR_PNPM_UNSUPPORTED_ENGINE— sameDone in 2.5s using pnpm v10.31.0Node 22.4.0 came from a real
nvm install 22.4.0; pnpm 9.15.9 from a realnpm install pnpm@9. The below-floor node run puts 22.4.0 onPATHas the only node, because pnpm re-execs itself when the manifest declarespackageManagerand would otherwise compare thePATHnode rather than the launching one — an earlier reading that looked like "the flag does nothing" was that confound, not a property of the flag.So the flag's delta is on the node axis only. Rows 3 and 4 are the load-bearing surprise:
engines.pnpmis already a hard failure today, with or without this flag, so this change adds nothing on the pnpm axis. What it changes isengines.node: a silent-ishWARNbecomes a refusal.Dependency engines were also exercised: the first install on this branch with the flag on was a genuine cold install of all 1621 packages across 47 workspace projects, exit 0. No dependency's own
enginesfield refuses at the current toolchain. Worth knowing that a future dependency bump declaring a higher node floor would now hard-fail rather than warn.Gate 2: the environments that would be refused
1. CI workflows — 12 workflows actually run
pnpm install, all above the floor.Enumerated by excluding comment lines, because a plain grep for
pnpm installalso matches four workflows whose comments discuss it (doc-component-types,doc-fence-languages,pre-install-import-graph,half-state-patrolare all deliberately install-free, and say so).Real install steps:
ci.yml(6 jobs),lint.yml,live-e2e.yml,node-esm-load-gate.yml,doc-snippet-types.yml,performance-budget.yml,published-dist-gate.yml,readme-exports.yml,shadcn-check.yml,spec-range-floors.yml,changeset-release.yml. Every one of them:corepack enable, thenactions/setup-node@v7withnode-version: '22.x', thenpnpm install --frozen-lockfile. pnpm comes from corepack against the rootpackageManager: pnpm@10.31.0, i.e. 10.31.0, above the>=10floor.node-version: '22.x'resolves to v22.23.2 (measured againstnodejs.org/dist/index.json, released 2026-07-28), above the 22.11 floor — and it corroborates the 22.23.2 the PM read in a CI job log. Note the floor is not free: 13 of the 35 released 22.x versions are below 22.11, so "node 22" is not automatically safe, only "latest 22.x" is.22.xmoves only upward, so this half is stable in the safe direction.2. Documented contributor setup — matches the floor exactly.
CONTRIBUTING.mdlines 23-24 already state Node.js 22.11+ and pnpm 10+, each tied to the declaration it comes from. Nothing to fix.The "Node.js 20+" in
content/docs/guide/quick-start.mdand "Node.js 20+ and pnpm 9+" incontent/docs/guide/building-crud-app.mdare outside this flag's radius: both describe building your own app withpnpm add @object-ui/*, not installing this repository. Confirmed structurally — no publishable package declaresengines, and there is no package-level.npmrc, so nothing here reaches consumers. Filed separately rather than fixed in this PR.3. Remote-agent session images — one sample, and the population stays UNVERIFIED.
The container this branch was built in reads node v22.22.2, pnpm 10.31.0 — above both floors. That is one image measured from the inside, not the fleet. The repository pins nothing that would let the fleet be enumerated: no
.nvmrc, no.tool-versions, nodevcontainer.json, noDockerfile, and no node version in.claude/,.agents/,.vscode/or.mcp.json.pnpm installthe moment this merges, and the failure appears before any of this card's context is visible to whoever hits it. Two things bound that risk but do not close it: such an image is already emittingWARN Unsupported engineon every install today, and the pnpm axis is already hard-failing today regardless of this flag.Gates
node scripts/check-changeset-presence.mjs— exit 0:✅ No source of a released package changed in this range, so no changeset is owed.No changeset added, and no label applied (objectui has noskip-changesetmechanism; the gate's own verdict is what closes this).node scripts/check-control-bytes.mjs— exit 0:✅ check-control-bytes: OK (scanned 5229 tracked text file(s); skipped 85 binary).Plus a directgrep -naPcontrol-character scan of.npmrc: no matches.node scripts/check-pre-install-import-graph.mjs— exit 0:✅ check-pre-install-import-graph: OK — 16 pre-install step(s) in 15 job(s) run 16 scripts/ gate(s); 18 module(s) walked, every non-relative leaf a node builtin.pnpm install --frozen-lockfilegreen on an above-floor toolchain (cold, 1621 packages) and refusing below the floor, as tabulated above.All gate runs above are on the final commit of this branch,
34f337cb4.Why it is a draft
Every environment that could be enumerated is above the corrected range, and no environment was found that fails it — so nothing here is a prerequisite fix, and the range was not widened. The open item is population 3: whether the session-image fleet is uniformly above the node floor is not something this seat can measure. That is a maintainer call, which is why this is a draft rather than ready.
Generated by Claude Code