Repository navigation
fix(create-plugin,root): pin jsdom to the 29.1 line so the Node install floor is 22.13 (objectui#11366) - #11509
Merged
objectstack-fleet[bot] merged 2 commits intoOct 2, 2026
Conversation
…oor stays at Node 22.13 (objectui#11366) The root `jsdom` devDependency (the version anchor the create-plugin scaffold copies) was `^30.0.1`. jsdom 30 declares engines.node `^22.22.2 || ^24.15.0 || >=26.0.0`, so with `engine-strict=true` every `pnpm install` on Node 22 below 22.22.2 was refused, while root `engines.node` still admitted `>=22.11`. - root `jsdom` and the scaffold's `DEV_DEPENDENCIES` entry move to `^29.1.1` (engines `^20.19.0 || ^22.13.0 || >=24.0.0`); - `pnpm-lock.yaml` is regenerated by `pnpm install`; jsdom@30.0.1, undici@8.9.0 and whatwg-url@17.1.0 leave it; - root `engines.node` becomes `>=22.13`, the highest lower bound the locked dependencies installed on linux-x64 set on the 22 line (eslint 10, @inquirer/*, @pnpm/deps.graph-sequencer, jsdom 29); - CONTRIBUTING.md and QUICK_REFERENCE.md follow the floor; the `.npmrc` comment stops restating it; - `@object-ui/create-plugin` patch changeset. Claude-Session: https://claude.ai/code/session_01YLg8XqWGJ785fwQ5v4pH37 Co-authored-by: Claude <noreply@anthropic.com>
github-actions
Bot
added
documentation
Contributor
|
changeset-claim-re-read
|
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
…ge's matchesGlob error (objectui#11366) The error thrown when `node:path` lacks `matchesGlob` said package.json declares `engines.node: ">=22.11"`, which went stale when the root floor moved to `>=22.13`. It now points at the root `engines.node` floor without restating a number, the same way the `.npmrc` comment does. The check, the throw and the rest of the message are unchanged. Claude-Session: https://claude.ai/code/session_01YLg8XqWGJ785fwQ5v4pH37 Co-authored-by: Claude <noreply@anthropic.com>
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
objectstack-fleet
Bot
deleted the
claude/issue-11366-jsdom-29-node-floor
branch
October 2, 2026 22:19
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
2 participants
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 #11366
Clause-②: no
What changed
The root
jsdomdevDependency is the version anchor that@object-ui/create-plugincopies into every generated plugin. It was^30.0.1. jsdom 30 declaresengines.nodeas^22.22.2 || ^24.15.0 || >=26.0.0, and.npmrcsetsengine-strict=true, sopnpm installrefused every Node 22 release before 22.22.2, even though rootengines.nodestill said>=22.11. The maintainer's position on the card (option 1) is to roll jsdom back and not raise the floor to 22.22.2. That is what this PR does.package.json:jsdomgoes from^30.0.1to^29.1.1, the newest 29.1.x (npm view jsdom@29; engines^20.19.0 || ^22.13.0 || >=24.0.0).engines.nodegoes from>=22.11to>=22.13.packages/create-plugin/src/templates.ts: thejsdomentry ofDEV_DEPENDENCIESand its anchor-table row follow the root.templates.test.tsreads the expected range from the root manifest, so no test literal had to change.pnpm-lock.yaml: regenerated bypnpm installwithengine-stricton, with no hand edits (method below).jsdom@30.0.1,undici@8.9.0andwhatwg-url@17.1.0are gone. jsdom 29.1.1 usesundici@7.29.0andwhatwg-url@16.0.1, which were already in the lockfile.CONTRIBUTING.mdandQUICK_REFERENCE.mdstate the new floor. The.npmrccomment no longer repeats the number. It points at rootenginesinstead, and it says what it means when a Node version the floor admits is refused..changeset/11366-create-plugin-jsdom-29.md: apatchfor@object-ui/create-plugin, because the generated plugin'sjsdomrange changes. The root package is private, so the floor change needs no changeset of its own.Why the floor is 22.13
I read every
packagesentry in the regenerated lockfile and kept the ones pnpm installs on linux-x64-glibc. An entry was dropped if itsos/cpu/libcfields excluded this platform, or ifnode_modules/.modules.yamllisted it asskippedafter a fresh install. The pnpm list adds two entries the platform fields miss:@img/sharp-wasm32and its@emnapi/runtime. For each remainingengines.noderange, I found the lowest 22.x.y version that satisfies it, usingsemver.Range(which parses spaced ranges like>= 20.12.0correctly).engines.node, and none of them rules out the 22 line entirely.eslint@10.8.1,@eslint/*,espree,eslint-scope,eslint-visitor-keys),@inquirer/*,@pnpm/deps.graph-sequencerandjsdom@29.1.1itself.Proof: same container, engine-strict on, no override
None of the runs below pass
--config.engine-strict=false. Each one starts with everynode_modulesremoved and runspnpm install --frozen-lockfile.fcdc8ec91ERR_PNPM_UNSUPPORTED_ENGINE·Your Node version is incompatible with "jsdom@30.0.1(@noble/hashes@2.3.0)"·Expected version: ^22.22.2 || ^24.15.0 || >=26.0.0e5eee15d8Lockfile is up to date, resolution step is skippede5eee15d8SHASUMS256.txt)e5eee15d8ERR_PNPM_UNSUPPORTED_ENGINE· root manifestExpected version: >=22.13How the lockfile was regenerated
After the manifest edit, a plain
pnpm installleftjsdom@30.0.1in the lockfile, now flaggedoptional: true, under thevitestsnapshots of 17 workspace packages. Each of those packages resolves vitest's optionaljsdompeer by auto-install, and pnpm picks that version as the highest one already in the lockfile (getHoistableOptionalPeersin pnpm 10.31.0). That keeps a stale version alive indefinitely.pnpm dedupe,pnpm install --fix-lockfileandpnpm update -r --depth Infinity jsdomdid not remove it.What did remove it, still without hand edits:
pnpm installwith a temporary rootpnpm.overridesentry"jsdom": "^29.1.1".pnpm installrun once more.The committed lockfile is a fixed point: a third
pnpm installleaves it byte-identical. The diff against BASE is limited to the jsdom subtree and the vitest peer suffixes, with one exception. Pnpm also wrote 12deprecated: yuku-analyzer runs on yuku-core since 0.14lines from current registry metadata onto the@yuku-analyzer/binding-*entries. These have nothing to do with jsdom, but any later regeneration would write them too.Tests and gates (all on
e5eee15d8, worktree root)pnpm exec vitest runonpackages/create-plugin/src/__tests__/plus everyscripts/__tests__file that reads rootengines,CONTRIBUTING.mdorQUICK_REFERENCE.md:check-changeset-presence,check-phantom-dependencies,doc-version-claims,quick-reference-current-release-4143,sync-quick-reference-release,check-doc-links,ci-cd-pipeline-doc,quick-reference-commands-4149. No test reads.npmrc. Result:Test Files 11 passed (11)·Tests 408 passed (408).pnpm --filter @object-ui/create-plugin build+type-check:ESM ⚡️ Build success,DTS ⚡️ Build success,VERDICT command-exit 0.pnpm check:unused-deps✅ ·pnpm check:phantom-deps✅ ·pnpm docs:check-linksLinks are valid across 17 scan roots.·pnpm check:control-bytes✅ ·pnpm check:new-line-citationsVERDICT … 0 new citation(s)·node scripts/check-changeset-presence.mjs✅ ·pnpm changeset:check✅ ·pnpm check:changeset-claims(report-only) ·pnpm quick-reference:check✅ ·pnpm check:lockfile-integrityVERDICT clean — no @objectstack/* identity moved backward and no package gained a copy.·pnpm check:lockfile-dedupeVERDICT deduped.check:changeset-claimsnamed three pending changesets that mentionpnpm-lock.yaml(5793, 6361, 7122). I re-read them. All three are about@objectstack/*resolutions, and this diff moves zero@objectstacklockfile lines, so they stay true.buildPluginFilesgenerates into a throwaway directory two levels below the worktree root, matching the realpackages/plugin-NAMEdepth, soextends: '../../tsconfig.json'resolves. Then I ran the generated example test under the generatedtestblock (globals,environment: 'jsdom',setupFiles), copied verbatim. Result:Test Files 1 passed (1). A probe test assertingnavigator.userAgentcontainsjsdom/29.1.1also passed, so the run really used jsdom 29.1.1. The directory was then deleted. This was a one-off check; no repo path runs the generated test against the root jsdom.e0639b06f, seat ruling A in claim amendment5961960157):scripts/check-lint-rule-coverage.mjs'smatchesGloberror text stops restating the floor as">=22.11"and points at the rootengines.nodefloor instead (2 lines out, 2 in; no logic change).check-lint-rule-coverage.test.ts: 35 passed. A fresh strict frozen install on Node v22.22.0 still exits 0.mainmoved only by PR objectui#11502, which touches no manifest, lockfile or this script, so no merge. Every remaining non-governed22.11hit was read: a pending changeset's history,@changesets/*'s own engines in the lockfile, and worked examples in docblocks. None states this repo's floor.Acceptance notes
scripts/check-lint-rule-coverage.mjshas an error message that says package.json declaresengines.node: ">=22.11". It is stale after this PR. The message only fires whennode:pathhas nomatchesGlob, which means Node below 22.5. The dispatch asked for every non-governed22.11floor statement to be corrected, but this file is not in the claim's surface, and a surface breach means stop. So I did not edit it. A one-line follow-up should drop the literal, for example by saying the rootengines.nodefloor is above 22.5. No governed file (skills/**,.claude/**,AGENTS.md) states the floor..npmrccomment no longer has a number. It used to repeat the floor, and nothing checks it. That repeated number is the shape of this card: a restated floor that drifted from what the install enforces (AGENTS.md 完善设计器的每一个细节 #9). It now points at rootengines..github/dependabot.ymlgroups only minor and patch updates, anddependabot-auto-merge.ymlonly enqueues those. So a jsdom 30 major would arrive as its own Dependabot PR, waiting for a human. Merging it would put the floor back at 22.22.2, and CI would stay green because it runs22.x. Whoever reviews that PR has to make the floor call.Session:
https://claude.ai/code/session_01YLg8XqWGJ785fwQ5v4pH37Generated by Claude Code