refactor(react, docs): derive component props from the API schema, drop react-docgen

[luvkapur]

What

The properties tables in the docs UI were fed by react-docgen 5.3.1 through the legacy ConsumerComponent.docs doclets. This points ReactMain.getDocs at the TypeScript schema extractor instead and removes react-docgen entirely.

Two UI surfaces consume getDocs, and both migrate here:

• the Compositions page's properties tab (compositions.tsx → useDocs)
• the Overview properties table (docs-app → PropertiesTable → useFetchDocs)

Neither UI component changed — only the resolver's data source — so there is no client rewiring and no transport change.

Why

react-docgen ran for every non-test file on every cold-cache component load: 3,224 parses in this workspace, of which 2,942 produced nothing and fell through to the jsdoc parser. It also read props without type information, so it could only describe what it could pattern-match out of the source.

The schema extractor already computes this data for the API Reference tab, and describes props precisely. The package was also pinned at 5.3.1 against a 7.x upstream with an incompatible API, so it was never going to be updated.

Verification

npm run lint (tsc + oxlint) clean; bit compile clean on all 332 components; 9 new unit tests for the mapper.

The mapper was run against real schema artifacts, and prop counts match react-docgen exactly:

component	schema	react-docgen
design/ui/avatar	8	8
preview/ui/component-preview	15	15
lanes/ui/inputs/lane-selector	14	14
component/ui/version-dropdown	7	7
design/ui/tooltip	3	3
design/ui/time-ago	2	2

Also verified end to end against a running bit start GraphQL server. The schema output is strictly richer — isTag?: (version?: string): boolean = (version) => semver.valid(version) !== null where react-docgen gave a bare signature, including default values it never captured.

Aspect graph: no new edge. SchemaAspect was already a declared dependency of ReactAspect and schemaMain was already injected into the provider; this only threads the existing instance into the constructor. There is no reverse schema → react edge, and bit status loads all 332 components without a circular-dependency error.

Review notes

• Perf is the thing to scrutinise. getDocs went from reading a field to potentially running a schema extraction. For built components it reads the build artifact; for workspace components it runs the extractor (~9s cold via CLI, warm after tsserver is up). Concurrent requests for the same component are deduped by an in-flight map, and nothing is cached past settle so a workspace component is never described from a stale schema. Worth a sanity check on a large workspace.
• bit show --legacy behaviour change: docs are now jsdoc-only, so React components lose their prop tables there. That command is the only remaining consumer of ConsumerComponent.docs, which stays populated by the jsdoc parser. Version.id() excludes docs, so no version hashes change.
• pnpm-lock.yaml is intentionally not regenerated — CI runs plain bit install (no --frozen-lockfile), and regenerating locally produced ~33k lines of unrelated churn.

Unrelated pre-existing issues noticed

• bit schema <pattern> --json fails arg parsing with Unknown argument: json and prints help.
• components/semantics/doc-parser/jsdoc/jsdoc-parser.spec.ts fails to load under mocha with an ESM/CJS ERR_UNKNOWN_FILE_EXTENSION; reproduced identically on master.

🤖 Generated with Claude Code

[luvkapur]

CI note

e2e_test fails on this branch, but not because of this change — master fails the identical two tests. Both are the file-count performance guard in e2e/performance/filesystem-read.e2e.ts, with 118 passing / 2 failing on both:

branch	bit init	bit status
master (671aa23fa, build 440970)	2446 (max 1100)	2627 (max 1515)
this PR (build 441029)	2203	2384

So this PR actually reduces the count the guard measures, by ~240 files in each case — consistent with dropping react-docgen and its transitive babel parsing from the load path. It is still over the threshold, which is a pre-existing master problem and looks like what #10599 is addressing.

I deliberately did not bump the thresholds or regenerate files-snapshot.txt here; that would mask the regression the guard is reporting on master.

Every other check passes: lint, generate_and_check_types, check_circular_dependencies, check_version_sync, check_generated_reference, bit_pr.