finding(components): noImplicitAny is off package-wide, and 26 renderer signatures depend on it

[yinlianghui]

Found while type-checking @object-ui/components' tests for #4040 (tranche 4). Observation-class: no user-visible symptom, no fix proposed here.

What

packages/components/tsconfig.json sets noImplicitAny: false:

// Removed rootDir to prevent file not under rootDir errors when importing from ..
"noImplicitAny": false,

The comment above it explains the rootDir removal, not the flag. It is the only package in the workspace that relaxes a strict sub-flag, and AGENTS.md commandment #6 is "type safety over magic — no any".

Measured cost, by compiling the package's test project once with the flag and once without (the difference is entirely in SOURCE files, not tests):

file	implicitly-any sites
src/renderers/navigation/sidebar.tsx	10 (TS7031, all { schema } / { className } binding elements)
src/renderers/action/action-bar.tsx	6 (TS7006, (a) => … / (action) => …)
src/renderers/action/action-menu.tsx	4
src/renderers/action/action-group.tsx	4
src/renderers/data-display/tree-view.tsx	2
total	26

Only 2 implicit-any sites are in the package's own tests, which is worth recording on its own: the TEST_DEBT registry described this package as TS7006x12, TS7031x12 — untyped test callback params, and that attribution is wrong. Those 24 are untyped renderer params that a measurement config re-enabling the flag pulled in through the tests' imports.

Why now

The tranche-4 tsconfig.test.json mirrors this one flag from the build config and nothing else, with the reasoning inline: a test project must not become the compiler of record for a SOURCE strictness decision that tsconfig.json owns. So graduating the package did not silently adopt the relaxation, and did not silently tighten it either.

The decision, when someone takes it

Turning the flag on is 26 signatures across five files, mechanical but not free, and it is a change to the published output's types (these are renderer props). Two sub-questions worth separating: whether sidebar.tsx's ten { schema } bindings want a real schema type or ComponentRendererProps (they are all renderer entry points), and whether the action renderers' (a) => callbacks should be typed from ActionDef — which would make them the sixth consumer of a type they already receive at runtime.

[yinlianghui]

CLAIM + RULING — PM seat session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4353-components-no-implicit-any, one dev agent, one PR, Fixes #4353. finding → pm:queue.

Ruling (delegated, veto window open): turn the flag on — AGENTS.md #6 is categorical, this is the workspace's only strict-relaxing package, and the flag's own comment doesn't even claim to justify it. The 26 source sites + 2 test sites get real types. Sub-questions ruled by the derivation doctrine:

1. sidebar.tsx's ten { schema } entry points: type them the way the package's OTHER renderer entry points are typed — measure the sibling convention first (ComponentRendererProps vs per-registry schema types) and follow it; do not invent a third spelling.
2. The action renderers' (a) => callbacks: typed from ActionDef — they already receive it at runtime, and becoming its sixth consumer is derivation-over-enumeration working as intended.

Published-types note: these are renderer props, so if any exported type visibly changes shape, grade the changeset per the #4403 precedent (minor with semantics); pure inference-tightening with unchanged declarations → patch. Never major. Concurrency note: #4354 is in flight on this package's data-table.tsx — file-disjoint from your five; both PRs run the same package gates and the merge queue arbitrates the tsconfig interaction.

---

Generated by Claude Code