Skip to content

chore(repo): enforce the declared node/pnpm floors at install time - #6351

Draft
os-warren wants to merge 1 commit into
mainfrom
claude/issue-6264-engine-strict
Draft

chore(repo): enforce the declared node/pnpm floors at install time#6351
os-warren wants to merge 1 commit into
mainfrom
claude/issue-6264-engine-strict

Conversation

@os-warren

Copy link
Copy Markdown
Collaborator

Fixes #6264

Adds engine-strict=true to .npmrc, so the root engines range 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. Root package.json reads exactly:

"engines": { "node": ">=22.11", "pnpm": ">=10" }

Premise holds; root package.json is untouched by this PR. The diff is one file.

The measurement that counts: the refusal

A green install proves nothing here — engine-strict only 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:

toolchain engine-strict exit verdict line
node 22.4.0 (below floor), pnpm 10.31.0 on 1 ERR_PNPM_UNSUPPORTED_ENGINEExpected version: >=22.11 / Got: v22.4.0
node 22.4.0, pnpm 10.31.0 off 0 WARN Unsupported engine: wanted: {"node":">=22.11"} (current: {"node":"v22.4.0","pnpm":"10.31.0"})
node 22.22.2, pnpm 9.15.9 (below floor) on 1 ERR_PNPM_UNSUPPORTED_ENGINEExpected version: >=10 / Got: 9.15.9
node 22.22.2, pnpm 9.15.9 off 1 ERR_PNPM_UNSUPPORTED_ENGINE — same
node 22.22.2, pnpm 10.31.0 (both above floor) on 0 Done in 2.5s using pnpm v10.31.0

Node 22.4.0 came from a real nvm install 22.4.0; pnpm 9.15.9 from a real npm install pnpm@9. The below-floor node run puts 22.4.0 on PATH as the only node, because pnpm re-execs itself when the manifest declares packageManager and would otherwise compare the PATH node 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.pnpm is already a hard failure today, with or without this flag, so this change adds nothing on the pnpm axis. What it changes is engines.node: a silent-ish WARN becomes 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 engines field 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 install also matches four workflows whose comments discuss it (doc-component-types, doc-fence-languages, pre-install-import-graph, half-state-patrol are 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, then actions/setup-node@v7 with node-version: '22.x', then pnpm install --frozen-lockfile. pnpm comes from corepack against the root packageManager: pnpm@10.31.0, i.e. 10.31.0, above the >=10 floor.

node-version: '22.x' resolves to v22.23.2 (measured against nodejs.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.x moves only upward, so this half is stable in the safe direction.

2. Documented contributor setup — matches the floor exactly.

CONTRIBUTING.md lines 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.md and "Node.js 20+ and pnpm 9+" in content/docs/guide/building-crud-app.md are outside this flag's radius: both describe building your own app with pnpm add @object-ui/*, not installing this repository. Confirmed structurally — no publishable package declares engines, 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, no devcontainer.json, no Dockerfile, and no node version in .claude/, .agents/, .vscode/ or .mcp.json.

⚠️ This third of the gate is unverified and should be read as a gap, not as a pass. If any session image in the fleet runs node below 22.11 with pnpm at or above 10, every agent seat on that image breaks at pnpm install the 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 emitting WARN Unsupported engine on 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 no skip-changeset mechanism; 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 direct grep -naP control-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.
  • Install itself is the gate for this change: pnpm install --frozen-lockfile green 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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Follow-up to #5306: turn on engine-strict=true once the corrected engines range is validated against CI images and contributor environments

2 participants