Bug: pre-existing TS errors block pnpm run build on master (5 errors in test files, @types/react bigint/ReactNode)

[mvpereira-git]

Bug report — pre-existing TypeScript errors block pnpm run build / build:lib:client on master (5 errors in test files)

Summary

pnpm run build (and build:lib:client → tsc -b tsconfig.client.json) fails on current master (cd5ef814) with 5 TypeScript errors in 3 test files that are unrelated to any recent change — all ReactNode-vs-bigint incompatibilities from @types/react under exactOptionalPropertyTypes. This blocks the canonical build for any contributor (including CI on Windows).

Reproduction

• Fresh shallow clone of master at cd5ef814, Node v24.9.0, pnpm install (lockfile).
• pnpm exec tsc -b tsconfig.client.json → exit 1.

Errors (path:line)

packages/client/ui-conversation/tests/input-bar.client.spec.tsx(150,9): error TS2375
  Type '{ rightItems?: ... bigint ... }' is not assignable to type 'ComposerBarProps' with
  'exactOptionalPropertyTypes: true'. Types of property 'accessory' are incompatible.
  Type 'bigint' is not assignable to type 'ReactNode'.
packages/client/ui-renderer/tests/session-provider.client.spec.tsx(161,26): error TS2322
  Type 'React.ReactNode' is not assignable to type 'ReactNode'. Type 'bigint' is not assignable to type 'ReactNode'.
packages/client/ui-renderer/tests/session-provider.client.spec.tsx(184,26): error TS2322 (same)
packages/client/ui-renderer/tests/session-provider.client.spec.tsx(211,26): error TS2322 (same)
packages/test-support/client-runtime/tests/runtime.client.spec.tsx(326,34): error TS2322 (same)

The failing files are byte-identical to the original HEAD (git diff cd5ef814 -- <file> is empty), so the errors are pre-existing on master, not introduced by local work.

Likely cause

@types/react@18.3.31 widened ReactNode handling (or a bigint-typed value/new React type resolution under "types"/skipLibCheck settings in tsconfig.client.json) interacting with exactOptionalPropertyTypes: true in tsconfig.base.client.json. Worth checking whether a @types/react pin or a tsconfig.base.client.json skipLibCheck/ReactNode adjustment is intended.

Impact

• pnpm run build (used by CI and by the web dev loop pre-requisite) fails on the client phase.
• Contributors who only need the web dist must bypass the test-including typecheck (e.g. a src-only aggregate), which is not the documented path.

Suggested fix (for maintainers)

Either pin @types/react to a version whose ReactNode accepts bigint, or add skipLibCheck: true to the client typecheck aggregate, or adjust the three test files' fixtures. Happy to open a PR with the fix once external PRs are accepted (CONTRIBUTING.md currently declines external PRs).

[173787247]

Agreed — if git diff cd5ef814 -- those three test files is empty, this is a broken master typecheck, not a local change.

The failure mode matches exactOptionalPropertyTypes colliding with a ReactNode that now admits / intersects bigint under the current @types/react resolution. Contributors then cannot follow the documented pnpm run build path, and any Windows CI that runs build:lib:client will fail the same way.

Practical interim for people who only need a web dist: typecheck/build src and skip the client test aggregate — but that should not stay the official path.

For maintainers, any of these is enough:

• pin @types/react to a version whose ReactNode is compatible with these fixtures under exactOptionalPropertyTypes, or
• adjust the three test fixtures so optional accessory / children props are not inferred as bigint, or
• if the intent is “tests are not part of tsc -b tsconfig.client.json”, move them out of that project reference explicitly.

Until one of those lands, every fresh clone of this revision will look “broken at build” even with a clean tree.

[Mide69]

Checked the actual root cause guess and it doesn't hold up. I pulled the real @types/react@18.3.31 index.d.ts (the exact version pinned in pnpm-lock.yaml, confirmed only one resolved version site-wide, no duplicate copy) and its ReactNode type is:

ReactElement | string | number | Iterable | ReactPortal | boolean | null | undefined | DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES[keyof DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES]

That last part is the React 19 forward-compat escape hatch, but in 18.3.31 it's declared as an empty interface, so keyof {} is never and that whole branch contributes nothing. There is no bigint anywhere in this ReactNode definition. So "@types/react widened ReactNode to include bigint" isn't what's happening here, and pinning a different @types/react version on its own won't fix it, since the type itself never had bigint.

That means the bigint has to be coming from something in the repo's own source, not from upstream. packages/client/ui-primitives/src/JsonTree.tsx explicitly branches on typeof value === 'bigint' in a few places, so there's at least one real bigint-aware type living in the client packages already. All three failing call sites in your report go through createSlotRenderer().renderRoot(...), whose return type is declared as plain ReactNode in packages/client/ui-slots/src/renderer.ts:214, imported the normal way (import type { ReactNode } from 'react'), same package everywhere.

I did not manage to trace the exact expression that infers bigint without actually running tsc with --explainFiles or hovering the failing line in an editor, so I can't hand you the final root cause. But I can save you from chasing the @types/react angle: that part is confirmed not the cause. Worth checking whether something feeding into the slot host or owner props (schemastery-derived types show up a lot in this repo and can widen to include bigint) changed recently, even if the three test files themselves didn't.

[173787247]

Thanks @Mide69 — that correction is right, and it invalidates the “pin @types/react” angle I floated earlier.

Agreed takeaway:

1. @types/react@18.3.31’s ReactNode does not include bigint, so the widen is almost certainly in-repo (schemastery-derived props / slot host-owner types / bigint-aware UI like JsonTree) flowing into createSlotRenderer().renderRoot(...), not an upstream ReactNode change.
2. The report’s still-solid part remains: those three test files are unchanged vs cd5ef814, yet tsc -b tsconfig.client.json fails — so contributors still hit a broken documented build path on that revision.

Useful next probes (for whoever has the tree open):

• hover / --explainFiles on the failing renderRoot(...) / accessory sites to see which local type first admits bigint
• grep for bigint in client slot host / owner / schemastery schemas feeding those props
• decide fix shape: narrow the producer type, cast/fixture the three tests, or drop client *.client.spec.tsx from the tsconfig.client.json project reference if tests were never meant to gate build:lib:client

I’ll stop recommending an @types/react pin for this one.