`objectui check` exits 1 on any TypeScript project: every `tsconfig*.json` is JSONC and `JSON.parse` counts each one as an error — 64 errors and a failing `pnpm check` in this repo today

[os-support-ai]

Found while establishing the measured baseline for #5127. Outside that card's radius (different arm of the same command, different mechanism, different fix) — not carried into its branch. Filed unassigned, not claiming.

Symptom

objectui check run at this repository's root, on main (118419214), with the CLI built from source:

$ node packages/cli/dist/cli.js check
Object UI Schema Check
Analyzing 612 files...
x Invalid JSON in tsconfig.vitest-setup.json: Unexpected token '/', "// Type-ch"... is not valid JSON
x Invalid JSON in tsconfig.json: Expected double-quoted property name in JSON at position 187 (line 9 column 5)
x Invalid JSON in packages/types/tsconfig.test.json: Expected property name or '}' in JSON at position 4 (line 2 column 3)
... 61 more ...
Found 64 errors
$ echo $?
1

All 64 are tsconfig*.json files. Every one of them is valid JSONC — the format TypeScript actually specifies for tsconfig.json — and every one of them fails JSON.parse, on either a // comment or a trailing comma.

Mechanism

packages/cli/src/commands/check.ts globs **/*.{json,yaml,yml} and hands every .json hit straight to JSON.parse:

const content = JSON.parse(readFileSync(join(cwd, file), 'utf-8'));

A throw here is the only thing that increments errors, and a non-zero errors is the only thing that calls process.exit(1). So a comment in a tsconfig.json — the normal, documented way to write one — is reported as a malformed file and fails the run.

Severity: this is the blocking arm, not the noisy one

#5127 documents the warning arm of the same command and notes, correctly for its own probe directory, that warnings do not affect the exit code. That probe held a bare package.json only. Put a tsconfig.json next to it — i.e. make it a TypeScript project, which every real consumer of this CLI is — and the command fails:

mkdir -p /tmp/oc-tsconfig && cd /tmp/oc-tsconfig
printf '{\n // a comment, as tsconfig permits\n "compilerOptions": { "strict": true }\n}\n' ~ tsconfig.json
node "$REPO/packages/cli/dist/cli.js" check ; echo "exit=$?"
# x Invalid JSON in tsconfig.json: ...
# Found 1 errors
# exit=1

(~ above stands for the shell redirect, spelled out so the snippet survives issue rendering.)

The repo's own pnpm check script is node packages/cli/dist/cli.js check, so pnpm check fails in this repository right now — 64 errors, exit 1. It appears not to be wired into any workflow, which is presumably why nobody has hit it.

Boundary against #5127

Independent, and #5127 cannot fix this as a side effect. The parse happens before any judgement of the file's contents, so a positive-marker gate (the ruled direction C) cannot skip it — you have to parse a file to find out whether it carries a marker. The two defects sit on either side of the same try:

• this issue — the catch arm: valid JSONC counted as a malformed file, run fails;
• objectui check 把每个 JSON 文件的根 type 都当成组件键判定,于是在任何 Node 工程里都对 package.json 的 "type": "module" 报未知类型 #5127 — the try arm: a foreign root type judged as a component key, warning printed.

Fixing either leaves the other exactly as it is.

Directions, not prejudged

• Parse .json with a JSONC-tolerant reader. Matches what the ecosystem means by these files; tsconfig, .eslintrc.json, devcontainer.json and VS Code's own settings are all JSONC in practice. Adds a dependency (or a small tolerant pre-strip, which has its own string-literal edge cases).
• Keep strict JSON.parse but stop treating a parse failure on a file the tool was never asked about as an error — e.g. demote to a warning, or only hard-fail on files that positively read as ObjectUI schemas. Note this couples to whatever objectui check 把每个 JSON 文件的根 type 都当成组件键判定,于是在任何 Node 工程里都对 package.json 的 "type": "module" 报未知类型 #5127 lands, so sequencing matters.
• Narrow what is scanned in the first place, which is direction A on objectui check 把每个 JSON 文件的根 type 都当成组件键判定,于是在任何 Node 工程里都对 package.json 的 "type": "module" 报未知类型 #5127.

Recommend deciding this one together with #5127's marker, since the second and third options share machinery with it — but it needs its own decision because the exit-code semantics are a separate contract from the warning semantics.

Reproduce

With REPO the repository root:

cd "$REPO"
pnpm --filter @object-ui/types build && pnpm --filter @object-ui/cli build
node packages/cli/dist/cli.js check ; echo "exit=$?"

(The @object-ui/types build is needed first — dist/cli.js imports its dist/zod/index.zod.js at load time.)

[os-support-ai]

Claim: PM loop round 6
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5237-jsonc-tolerant-parse
Worktree: objectui-issue-5237
Domain: repo:objectui (execution seat)
File surface: packages/cli/src/commands/check.ts, packages/cli/package.json (one dependency line — see below), plus packages/cli tests. ⛔ OUT: packages/plugin-view / plugin-list (#5177), packages/auth + app-shell/providers (#5198), packages/plugin-grid (#5091), packages/components/src/renderers/form/** (#4259), packages/types (#5186 merged).
Container & model: S, mode:subagent, model: opus.
Clause-②: no — it stops rejecting files that were never malformed. It narrows nothing and publishes nothing.
Serial constraints cleared: packages/cli is free. #5127 was returned to needs-user-decision this round with no PR and no commits — its branch is empty and its claim released, so the other arm of this same command is not in flight. Nothing else touches packages/cli.

Scope — direction 1 ONLY (the JSONC parse), and it is deliberately DECOUPLED from #5127

This card lists three directions and recommends deciding alongside #5127's marker. I am scoping you to the first one, and the reason is in the card's own boundary section: the parse happens before any judgement of the file's contents, so a positive-marker gate cannot skip it — "Fixing either leaves the other exactly as it is." Only directions 2 and 3 couple to #5127.

That decoupling is the point. #5127's ruling was falsified by measurement this round and it is back in the maintainer's box. This defect is worse than #5127's and must not wait on it: #5127 prints a warning, while this one fails the run — exit 1 in any TypeScript project, 64 errors in this repo, and pnpm check red on main today.

⛔ Do not implement direction 2 (demote parse failures to warnings / hard-fail only on marker-carrying files) or direction 3 (narrow the scan). Both encode a decision that belongs to #5127 and to the maintainer. If you conclude direction 1 cannot be done without one of them, stop and report.

The dependency question — read this, it is the one thing that could make this card not yours

Direction 1 means parsing with a JSONC-tolerant reader, and the card correctly flags that this "adds a dependency". A new third-party runtime dependency is a maintainer-floor decision and is not mine to authorise.

I checked before dispatching, and it is not new: jsonc-parser@^3.3.1 is already a declared runtime dependency of @object-ui/app-shell and is already in pnpm-lock.yaml. So using it in @object-ui/cli adopts a package the product already ships and the org has already accepted — a new dependency edge, not a new dependency to the fleet. On that basis I am authorising it, and I am flagging the call to the maintainer in this round's report so it can be vetoed.

Your hard stop: @object-ui/cli is a published package. If adding jsonc-parser to it would pull any new transitive package into what users install, or if the version already in the lockfile cannot be satisfied without a bump elsewhere — stop and report. Verify this; do not assume it. ⛔ Do not reach for a different JSONC library, and ⛔ do not hand-roll a comment-stripping regex: the card names the reason (string-literal edge cases — a // inside a JSON string value is not a comment), and a subtly wrong stripper is worse than the bug.

Premise — re-verify, then reproduce

Verified on origin/main: check.ts globs **/*.{json,yaml,yml} and hands every .json straight to JSON.parse; a throw is the only thing that increments errors, and non-zero errors is the only thing that calls process.exit(1).

Reproduce it yourself before fixing — the card gives the recipe (note @object-ui/types must be built first; dist/cli.js imports its dist/zod/index.zod.js at load). Confirm the 64/exit-1 figure rather than quoting mine.

Tests

• A tsconfig.json with a // comment and a trailing comma parses cleanly, produces no error, and does not affect the exit code.
• Genuinely malformed JSON still errors and still exits 1. This is the assertion that stops the fix from becoming "never fail on anything" — a tolerant reader that swallows real syntax errors would pass a suite built only from the happy path.
• The warning arm is untouched: a file with an unrecognised root type still warns exactly as before, and still does not change the exit code. objectui check 把每个 JSON 文件的根 type 都当成组件键判定,于是在任何 Node 工程里都对 package.json 的 "type": "module" 报未知类型 #5127 must be left in precisely the state it is in.
• Repo-level: objectui check at the repo root goes from 64 errors / exit 1 to 0 errors / exit 0 (the 47 warnings stay — they are objectui check 把每个 JSON 文件的根 type 都当成组件键判定,于是在任何 Node 工程里都对 package.json 的 "type": "module" 报未知类型 #5127's, not yours).

Reverse-verify: restore check.ts, keep the tests, predict which go red before running, report predicted vs observed.

Gates

Derive from your diff (scripts/pm/dispatch-gates.mjs is objectstack-only; here derive from .github/workflows and package.json). A dependency addition may bring check-phantom-dependencies.mjs into play — run it. Changeset required (@object-ui/cli); patch or minor, ⛔ never major.

⛔ Do not background a long check and end your turn. Narrow and declare the narrowing if the shared verify lock is contended.

Deliver

Draft PR against main, first body line Fixes #5237. Push the branch early. Return the JSON report and post it as a comment whose first line is the literal <!-- os-dev-report --> marker.

---

Generated by Claude Code

[os-support-ai]

{
 "issue": 5237,
 "status": "done",
 "branch": "claude/issue-5237-jsonc-tolerant-parse",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5245",
 "premise_still_valid": true,
 "summary": "Direction 1 only: packages/cli/src/commands/check.ts now reads .json with jsonc-parser (comments allowed, allowTrailingComma: true, allowEmptyContent left off so an empty .json still errors exactly as JSON.parse('') did) instead of JSON.parse. Crucially the reader is error-TOLERANT and returns a best-effort value rather than throwing, so the command consults its reported-error array — without that, the fix would have degenerated into 'never fail on anything' and a happy-path suite would not have caught it. Errors now name reason plus line and column. The dependency hard stop was verified, not assumed: jsonc-parser@3.3.1 declares no dependencies and no peerDependencies (lockfile snapshot is literally `jsonc-parser@3.3.1: {}`), it is already a runtime dep of @object-ui/app-shell at the same resolved version, and the entire pnpm-lock.yaml delta is 3 lines confined to the packages/cli importer entry — zero new resolutions, zero new snapshots, no bump anywhere. Directions 2 and 3 were not implemented and #5127's warning arm is untouched.",
 "tests": "All on final commit 565cfad06, clean tree. REPRO on the branch point 118419214: `node packages/cli/dist/cli.js check` at repo root = 'Found 64 errors', exit=1, 47 warnings; all 64 error files matched tsconfig* (grep for non-tsconfig error files returned none). AFTER on 565cfad06: '✓ All checks passed', exit=0, errors=0, warnings=47 unchanged. TESTS: `pnpm exec vitest run packages/cli/` -> 'Test Files 8 passed (8) / Tests 179 passed (179)', 15 of them new in packages/cli/src/__tests__/check-jsonc-parse.test.ts. Run from the REPO ROOT because this repo's guard rejects package-directory vitest as a false-green trap (objectui#3378) — `pnpm --filter @object-ui/cli test` is refused by that guard, not by a failure. type-check: `pnpm --filter @object-ui/cli type-check` -> 'tsc --noEmit' echoed, RC=0 (script name verified to rule out a zero-match silent pass; note objectui spells it `type-check`, hyphenated). lint: 0 errors, 11 pre-existing warnings, none in the changed files. GATES derived from the diff via .github/workflows + package.json (dispatch-gates.mjs is objectstack-only): check:phantom-deps ('Every in-scope import is declared by the package that publishes it'), check:control-bytes ('scanned 4643 tracked text file(s)'), check:self-import, check:published-dist ('39 published package(s), 0 tooling artifact(s)'), changeset:check ('No changeset declares a major bump'), check:esm-specifiers, check:node-esm-load — all exit 0; @object-ui/cli is in the ESM-load gate's scope and is NOT among its failures (those are all pre-existing ledgered objectui#5214 entries). Also verified jsonc-parser stays EXTERNAL in the tsup output (dist/cli.js line 680 imports it by bare specifier), so the built CLI exercises real runtime resolution — which matters because jsonc-parser's ESM build uses extensionless relative imports and Node therefore resolves it through its CJS `main`; named-import interop confirmed by executing dist/cli.js end to end. Byte discipline: a raw ESC (0x1b) was materialised into the test file by the editing tool while writing an ANSI regex; caught with `cat -A`, rewritten as String.fromCharCode(27), and `grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]'` over the changed files is now clean. REVERSE VERIFICATION (fix committed first, then check.ts restored from origin/main, tests kept): predicted 5 red / 10 green and named the five BEFORE running; observed exactly 5 red / 10 green, the same five — (1) tsconfig with comment+trailing comma, (2) `//` inside a string value, (3) the line/column message shape (V8 says 'at position N (line...)', never 'at line'), (4) a real error counted beside a valid JSONC sibling (old code counts 2, not 1), (5) the warning arm reached through a JSONC file. The six genuinely-malformed cases stayed GREEN under the old code, which is what makes them load-bearing: they pin behaviour the fix had to preserve, not behaviour it introduced. No rebuild is involved in either leg and none is required: the tests import '../commands/check.js', a relative specifier vitest resolves to TypeScript SOURCE, not through the package's exports to dist/ — confirmed empirically, since the new tests passed while dist/ still held the pre-change build. Fix then restored from the branch; `git status` clean, so byte-identical to the commit.",
 "open_questions": [
 {
 "question": "PM authorised the jsonc-parser dependency edge for the published @object-ui/cli on the basis that the fleet already ships it; the maintainer may still want to veto. Recording the measured basis so the call can be made on evidence rather than on my say-so.",
 "options": [
 "A — keep jsonc-parser in @object-ui/cli: zero new transitive packages (it declares no dependencies and no peerDependencies), same version already resolved in the lockfile, lockfile delta is 3 lines in the packages/cli importer only, and @object-ui/app-shell already ships it to users.",
 "B — veto the edge and revert to strict JSON.parse: this restores the defect in full (exit 1 in every TypeScript project), so it is only coherent if paired with direction 2 or 3, which belong to #5127 and to the maintainer.",
 "C — vendor a JSONC reader into the CLI instead of depending on one: no new edge, but it re-creates the string-literal edge cases the card warns about and puts a parser under our maintenance for no measured benefit."
 ],
 "recommendation": "A. The hard stop the dispatch set was 'any new transitive package into what users install, or a version that cannot be satisfied without a bump elsewhere' — both measured false. Net effect on an install is one package the product already ships. C is the option to avoid: hand-rolling is exactly what the card rules out, and a subtly wrong stripper is worse than the bug it replaces."
 },
 {
 "question": "The fix changes which arm a file lands in, and this is a real behaviour change worth the maintainer seeing rather than discovering: a JSONC file carrying an unrecognised root `type` used to ERROR at the parse step and now reaches #5127's arm and WARNS instead.",
 "options": [
 "A — accept it as the direct consequence of direction 1: the parse step stopped rejecting files that were never malformed, so files it used to swallow now reach the judgement step.",
 "B — suppress the warning arm for files that carry comments, to hold the old output byte-for-byte."
 ],
 "recommendation": "A, and it is already the shipped behaviour. The warning arm's verdict and its exit-code neutrality are unchanged and pinned by tests; only its reach grows. B would encode a judgement about which files the warning arm should judge — precisely the decision that belongs to #5127 and the maintainer, and the thing I was scoped out of."
 }
 ],
 "out_of_scope_findings": [
 "filed as #5246: no workflow runs the root `pnpm check` script, so `objectui check` can sit red on `main` indefinitely — this is why 64 errors went unnoticed; searched first (no existing open issue), labelled `finding` only, unassigned, and deliberately not fixed here because wiring it in needs a decision about #5127's 47 warnings in a required job."
 ]
}

---

Generated by Claude Code