Repository navigation
scaffold(create-objectstack): measure npx -y create-objectstack@next on node 22 / npm 10 with pnpm absent — does 18.0 GA fix the latest install crash by itself? (#24445) #24487
Description
Filed by the director seat (summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax) on the maintainer's words of 2026-10-19 in this seat's chat, on #24445: 「等我发布了新的 v18 npx create-objectstack问题就能解决吗？要不要派一个卡测试一下」 then 「你只需要创建卡片」. A measurement card: it fixes nothing, changes no workflow, publishes nothing. ⛔ Not a claim.
Why
- [Decision] The nightly registry canary is red since 10-16:
npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445: the nightly registry canary (.github/workflows/scaffold-e2e.ymljobregistry-canary,:530ff) has been red since 10-16 becausenpx -y create-objectstack@latestresolves to 17.7.0, whose generated project crashes atnpm installon npm 10 (Cannot read properties of null (reading 'edgesOut')). npm 10 is what Node 20 and Node 22 bundle; the scaffolder falls back to npm only when pnpm is absent from PATH (detect-package-manager.ts), so the users hit are first-timers on an LTS Node with no pnpm. - The 18.x line carries two fixes: the blank template's
overrides.vitest(release(next): the Version Packages PR #23481 is red — npm 10 crashes withedgesOuton two lockfile-less installs (validate-deps vendor-export resolve, scaffold-e2e); fix on main, never on the generated branch #23788 / cli:os init/os createemit manifests npm 10 cannot install since vitest@4.1.12 (edgesOut); the CLI half of #23788's template override #23805,.changeset/pre/23788-blank-scaffold-npm10-vitest-override.md) and@objectstack/metadata-coredropping its optionalvitestpeer (finding: existing projects cannotnpm install @objectstack/plugin-author@objectstack/metadata-coreon npm 10 since vitest@4.1.12 (edgesOut); metadata-core's own optionalvitestpeer is one path in #23806). The nightly 「Scaffold with repo dist」 job is green on chore: version packages (next) #24168's head (a30a6dc4de, run39194689420) — but that job scaffolds with the repo-built scaffolder and framework, not with what the registry serves. Whether a new user gets a working install from the published@nextpackages on npm 10 has not been measured; the canary only ever runs@latest. - The maintainer's question is exactly that: once 18.0 is published and
latestmoves, doesnpx create-objectstackwork by itself, with no 17.x release?
What to measure
On a machine or container with Node 22 (npm 10.9.x) and pnpm absent from PATH (so the scaffolder takes the npm path a first-time user takes). Mirror the canary's steps at scaffold-e2e.yml:549ff; ⛔ do not edit the workflow (Tier H) — run it by hand.
- The case:
npx -y create-objectstack@next canary-app -t blank --skip-skills. Record the banner version (expected18.0.0-next.N), the package manager it chose, the full outcome of its install step, and whatever the canary runs after scaffolding (the sameobjectstackcommand the job runs). - The control: the same command with
@latest(expected: banner 17.7.0,edgesOutcrash,objectstack: not found). If the control passes, the premise of [Decision] The nightly registry canary is red since 10-16:npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445 has changed; say so. - The common path: repeat case 1 with pnpm on PATH (expected green; records which path the scaffolder took).
- Dist-tags at the time of the reading:
npm view create-objectstack dist-tagsandnpm view @objectstack/runtime dist-tags.
Done when
- The four readings are on this card verbatim (commands, versions, exit codes, the install log's last 20 lines on failure), and a one-line summary is posted on [Decision] The nightly registry canary is red since 10-16:
npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445 as a pointer. - Green on
@next(npm path): the reading says so, and that 18.0 GA movinglatestis expected to turn the canary green on its own; no 17.x release is needed for the new-user path. The maintainer's letter on [Decision] The nightly registry canary is red since 10-16:npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445 follows the reading. - Red on
@next: the reading names the failing step and the error, and a fix card is filed on the 18.x line (domain:devx) before GA; [Decision] The nightly registry canary is red since 10-16:npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445 stays open. - ⛔ No fix, no workflow change, no release in this card.
Dedupe
needs-user-decision and pm:queue cards read in this act: #24445 is the decision card (it names A / B / C and runs no measurement); no other card measures the registry path on @next. #23805 / #23806 / #23849 / #23966 are the 18.x fixes and their docs, all landed.
Related: #24445 (the decision; this card's reading precedes its letter), #24168 (the next version PR, merged), scaffold-e2e.yml (registry-canary), ADR none.
Activity
objectstack-fleet commentedon Oct 19, 2026
Claim: PM loop round 3 ·
priority:p1cut in on the maintainer's 「24487 插队」 in this session's chatSession:
session_01FM29ZqLTrnPNXxijioZwMpAccount:
os-warren(the seat's linked user asGET /useranswers it; the card's assignee)Branch:
claude/issue-24487-next-npm10-scaffold-reading(a measurement card: no PR expected)Worktree:
objectstack-issue-24487(read-only use; the scaffolds run in a scratch directory outside every worktree)Domain:
domain:devxSeat:
domain:devx#1File surface: none in the tree. Writes are the readings on this card, one pointer line on #24445, and, only on a red
@nextreading, one fix card on the 18.x line (domain:devx) through the filing gate. ⛔ No workflow edit (scaffold-e2e.ymlis Tier H), no fix, no release (stop on breach; explain in the report).Container & model:
S (four registry readings, by hand),mode:subagent,model: TIER_DEFAULT(dispatch-gates --tier: no file surface, so no path-derived mandate)Clause-②: no
Responsibility:
n/a — not a defect card(a measurement that precedes the maintainer's letter on #24445)Thread-read: none
Serial constraints cleared: none — the card touches no file; #24445 is its decision card (
needs-user-decision, no claim) and #24462 (pm:blocked) is the registry canary's own card; neither is in flight (read at 2026-10-19T07:18Z).Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
os-dev-report
{ "issue": 24487, "status": "done", "branch": "claude/issue-24487-next-npm10-scaffold-reading", "pr": null, "session": "session_01FM29ZqLTrnPNXxijioZwMp — the parent PM's harness-stamped id (subagent = parent's), as the dispatch and Claim 6261874232 name it", "premise_still_valid": true, "summary": "Measurement card, no tree change. Verdict: GREEN on @next (npm path). `npx -y create-objectstack@next canary-app -t blank --skip-skills` ran on node v22.22.0 / npm 10.9.4 with `command -v pnpm` empty and a cold npm cache. It printed the banner `Create ObjectStack v18.0.0-next.3`, chose npm, installed (`added 565 packages, and audited 566 packages in 1m`, scaffold exit 0) and passed the canary's post-scaffold steps: validate 0, build 0, test 0, health ok, ready 200. The @latest control (banner v17.7.0) reproduced #24445: `npm error Cannot read properties of null (reading 'edgesOut')`, scaffold exit 0 behind `Dependency installation failed`, then validate and build exit 127 with `sh: 1: objectstack: not found`. With pnpm on PATH (10.28.0), @next chose pnpm and went fully green. Both 18.x fixes are inside the published 18.0.0-next.3: the blank template carries overrides.vitest ~4.0.0 and is byte-identical to main's, and metadata-core@18.0.0-next.3 has no vitest peer. Main itself is at 18.0.0-next.4, which is unpublished. So 18.0 GA moving `latest` is expected to turn the registry canary green on its own, and no 17.x release is needed for the new-user path. Limits: next.3 is not GA; only npm 10.9.x was measured; Node 20's npm 10.8.x was not. No fix card was filed because the reading is green. Side effect: one `git fetch origin main` in the PM's worktree /home/user/objectstack-pm-devx1, which advanced the shared origin/main to ae6bd1a69 and rewrote that checkout's FETCH_HEAD. No file was edited anywhere in a tree, and no worktree, branch or push was made, because the card edits nothing.", "tests": "No repo tests: no file changed. Readings, each case in a fresh scratch dir outside every worktree with a fresh npm_config_cache. (1) PATH=/usr/local/bin:/usr/bin:/bin, pnpm=[] corepack=[]: `npx -y create-objectstack@next canary-app -t blank --skip-skills` gave SCAFFOLD_EXIT=0, banner v18.0.0-next.3, npm, `added 565 packages`. Then VALIDATE_EXIT=0, BUILD_EXIT=0, TEST_EXIT=0 (`Tests 1 passed (1)`), HEALTH ok after ~14s, READY_EXIT=0 `{\"success\":true,\"data\":{\"status\":\"ready\",\"state\":\"running\"}}`. (2) The same with @latest gave SCAFFOLD_EXIT=0, banner v17.7.0, `npm error Cannot read properties of null (reading 'edgesOut')`. Then VALIDATE_EXIT=127 and BUILD_EXIT=127 (`sh: 1: objectstack: not found`), no test script, BOOT_EXIT=1 (`npm error could not determine executable to run`). The install log's last 20 lines are on the card. (3) PATH with /opt/node22/bin first, pnpm 10.28.0, fresh pnpm store: @next gave SCAFFOLD_EXIT=0, banner v18.0.0-next.3, `Done in 9.7s using pnpm v10.28.0`, and validate, build, test, health and ready all 0. (4) dist-tags at 07:21:29Z and again at 07:29:32Z: create-objectstack, @objectstack/runtime and @objectstack/metadata-core each read { rc: '17.0.0-rc.6', latest: '17.7.0', next: '18.0.0-next.3' }. Contents check: `npm pack create-objectstack@18.0.0-next.3` gave a template package.json with overrides.vitest ~4.0.0, and `cmp` against main ae6bd1a69 exited 0; `npm view @objectstack/metadata-core@18.0.0-next.3 --json` shows peerDependencies absent, versus vitest ^4.0.0 optional on 17.7.0. Ablation: n/a, since no behaviour changed.", "gates": "Local subset: none from the tree. This card changes no file, so `dispatch-gates --commands` has no change set to derive from: NOT MEASURED by design, as the dispatch states. Exit codes were captured before any pipe: each run redirected to a file and read `$?` first. The three post-scaffold runs went through `scripts/pm/os-verify-lock.sh` with stable OS_VERIFY_LOCK_SLOT names, and each printed `VERDICT command-exit 0` (held 28s / 5s / 29s, waited 0s, shared-box seconds). CI check-runs: none to cite, because there is no PR. The registry canary workflow was not edited or dispatched.", "mcp_calls": "0 — no MCP GitHub tool called; reads were unauthenticated-header REST GETs through the container proxy (GET /issues/24487, /issues/24487/comments, /issues/24445, /issues/24445/comments)", "api_writes": "2 — via scripts/pm/post-stamped.mjs (fleet relay, transport auto): POST comment on #24487 (this os-dev-report), then POST comment on #24445 (the one-line pointer)", "open_questions": [], "out_of_scope_findings": [ "carrier: 承接者:无 · noted, not filed — observation, not a defect class: the scaffolder (17.7.0 and 18.0.0-next.3 alike, `execSync(pm install)` in a try/catch) exits 0 after a failed dependency install. It prints `Dependency installation failed. Run npm install manually.` and then `Environment created!`. So a scripted caller, the registry canary included, sees the failure first at the next step as `objectstack: not found`. Deliberate warn-and-continue design; recorded because it explains why the canary's red step is `Gate the generated project` and never the scaffold step. Dedupe words: create-objectstack install failure exit code, Dependency installation failed, scaffold exit 0, registry canary objectstack not found" ] }Verdict
GREEN on
@next(npm path).npx -y create-objectstack@next canary-app -t blank --skip-skillson node v22.22.0 / npm 10.9.4, withcommand -v pnpmandcommand -v corepackboth empty and a cold npm cache, printed the bannerCreate ObjectStack v18.0.0-next.3, took the npm path, installed (added 565 packages, and audited 566 packages in 1m) and passed every post-scaffold step the registry canary runs:npm run validate0,npm run build0,npm test0 (1 passed),npx os starthealthy,/api/v1/ready200. The@latestcontrol (banner v17.7.0) reproduces #24445 step for step. So 18.0 GA movinglatestis expected to turn the registry canary green on its own, and no 17.x release is needed for the new-user path. That expectation holds only within the limits at the end of this comment.What the published
18.0.0-next.3contains (both 18.x fixes: present)18.0.0-next.3, published2026-10-17T09:07:43.920Z(npm view create-objectstack time). Main atae6bd1a69carriespackages/create-objectstack/package.jsonversion18.0.0-next.4, so@nextis one version-packages generation behind main: the next.4 release (725a5b131, chore: version packages (next) #24168) is not on npm.os init/os createemit manifests npm 10 cannot install since vitest@4.1.12 (edgesOut); the CLI half of #23788's template override #23805 (blank templateoverrides.vitest): in next.3.npm pack create-objectstack@18.0.0-next.3, thenpackage/dist/templates/blank/package.jsoncarries devDependency"vitest": "~4.0.0"and"overrides": { "vitest": "~4.0.0" }.cmpagainst main'spackages/create-objectstack/src/templates/blank/package.jsonatae6bd1a69exits 0: the two files are byte-identical.npm install @objectstack/plugin-author@objectstack/metadata-coreon npm 10 since vitest@4.1.12 (edgesOut); metadata-core's own optionalvitestpeer is one path in #23806 (@objectstack/metadata-corewithout the optionalvitestpeer): in next.3.npm view @objectstack/metadata-core@18.0.0-next.3 --jsonshowspeerDependenciesabsent andpeerDependenciesMetaabsent. The same read on17.7.0showspeerDependencies {"vitest":"^4.0.0"}andpeerDependenciesMeta {"vitest":{"optional":true}}. Main'spackages/metadata-core/package.jsondeclares nopeerDependencies.@objectstack/*range to^+ its own version (syncObjectStackDeps). The@nextproject therefore depends on^18.0.0-next.3, and it resolved18.0.0-next.3for@objectstack/cli,runtime,specandmetadata-core, withvitestat4.0.18.Reading 1: the case (
@next, npm path, pnpm absent)Scaffold output (ANSI colour codes stripped; otherwise verbatim):
Post-scaffold steps (the canary's
Gate the generated project+Boot and probe health):Reading 2: the control (
@latest, npm path, pnpm absent)Scaffold output (ANSI colour codes stripped; otherwise verbatim):
The install log's last 20 lines (
npm-cache/_logs/2026-10-19T07_25_44_136Z-debug-0.log), verbatim:Post-scaffold steps:
The control matches the expectation on the card and the 10-19 canary run (
39195688836): banner 17.7.0, theedgesOutcrash,objectstack: not found. The premise of #24445 is unchanged.Reading 3: the common path (
@next, pnpm on PATH)Scaffold output (ANSI colour codes stripped; one marked elision, otherwise verbatim):
Post-scaffold steps:
Reading 4: dist-tags
Method and declared deviations
.../scratchpad/issue-24487/caseN-*). That is outside every git worktree:git rev-parse --show-toplevelprinted nothing in each case. Each case also had a freshnpm_config_cache. Reading 3 additionally had a fresh pnpm store and cache dir, and its install line showsreused 0.env -iwas never used, so the proxy and CA settings stayed in place. The npm path usedPATH=/usr/local/bin:/usr/bin:/bin. Therenode,npmandnpxare symlinks into/opt/node22/bin, and neitherpnpmnorcorepackresolves.bundoes resolve there (/usr/local/bin/bun), which does not matter:detect-package-manager.tsprobes pnpm only. The pnpm path used/opt/node22/binfirst; therepnpm --versionanswered10.28.0in the scratch dir.Next stepsnamesnpm run dev,package-lock.jsonwas created, and no pnpm-fallback warning printed. pnpm in reading 3:Done in 9.7s using pnpm v10.28.0andpnpm-lock.yamlwas created.scaffold-e2e.ymljobregistry-canaryatae6bd1a69(lines 549-596):npm run validate(objectstack validate),npm run build(objectstack build),npm test(vitest run), thennpx os start --artifact ./dist/objectstack.json --port PORT, polling/api/v1/healthand reading/api/v1/ready. The workflow was not edited. Deviations from CI:bash -estops at the first nonzero (in reading 2 that isvalidate);NODE_OPTIONS=--max-old-space-size=4096;CIwas unset, as in a first-time user's shell.npx create-objectstack@latestis 17.7.0, whose install crashes on npm 10 (edgesOut), and 17.x is frozen — canary on@nextuntil 18.0 GA (A), a scaffolder-only 17.7.1 (B), or wait (C)? #24445). The control reproduces the crash here, so this container reproduces the failure the canary sees.Limits of the GA expectation
18.0.0-next.3; GA will be cut from main. For the two fixes this card is about, main matches next.3: the templatepackage.jsonis byte-identical, and metadata-core declares no peer. Anything else that changes between next.3 and GA is covered by the nightly 「Scaffold with repo dist」 job, not by this registry-path reading.Dependency installation failedand thenEnvironment created!. That is why the canary's scaffold step stays green and the failure first surfaces one step later, asobjectstack: not found. On GA the first red step will likewise beGate the generated project, never the scaffold step.Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
ACCEPT and close ·
domain:devxseat 1 ·os-warren·session_01FM29ZqLTrnPNXxijioZwMp· 2026-10-19T07:35Z · review of theos-dev-report62620798846262079884carries all four: (1)@next, npm path: bannerv18.0.0-next.3,command -v pnpmempty,added 565 packages,SCAFFOLD_EXIT=0, validate, build, test, boot and/api/v1/readyall 0; (2)@latestcontrol: bannerv17.7.0,edgesOut, validate and build 127 (objectstack: not found), with the install log's last 20 lines; (3) pnpm on PATH: green; (4) dist-tags read twice6262097446@next(npm path)18.0.0-next.3: the blank template is byte-identical tomain's (overrides.vitest ~4.0.0), and@objectstack/metadata-core@18.0.0-next.3declares nopeerDependenciesSeat spot-check at this act (registry, not the dev's transcript):
npm view @objectstack/metadata-core@18.0.0-next.3 peerDependenciesanswers nothing, and17.7.0answers{"vitest":"^4.0.0"};create-objectstackdist-tags still read{ rc: '17.0.0-rc.6', latest: '17.7.0', next: '18.0.0-next.3' }.Limits carried to the decision, not resolved here:
next.3is not GA; only npm 10.9.x was measured (Node 20's bundled npm 10.8.x was not). The dev also noted that the scaffolder exits 0 after a failed dependency install (warn-and-continue), which is why the canary's red step is the post-scaffold gate. That was noted, not filed.The maintainer's letter on #24445 follows this reading; this seat answers nothing there. Closing
completed;pm:dispatchedcomes off in the same act.Generated by Claude Code