facebook/react

codes.json registry shape + ReactVersion.js propagated to 3 per-package fields — structural drift even at the most evolved end of the JS monorepo spectrum.

Narrative
Catches conventions your pipeline assumes but doesn't verify
Rules
87
Last revalidated
Engineering reference
README on GitHub · .alint.yml

Why this matters

react is the canonical deeply-evolved JS monorepo with selective custom tooling — a Yarn classic v1 workspace of 39 packages (22 published, 17 private), 5 lint-class CI jobs, 8 hand-rolled validation scripts under scripts/, 5 in-tree custom eslint rules, and a PR-time Danger runner. Different shape from kubernetes (Go + 50 verify-script empire), microsoft/typescript (Hereby task runner, frozen-snapshot maintenance mode), and vercel/turbo (modern Rust+TS hybrid with zero hand-rolled validators).

react sits in the middle of the spectrum: 8 hand-rolled scripts and ~10 conventions enforced only by code-review etiquette. The existing tooling (eslint + prettier + flow + the 5 custom eslint rules + Danger) is mature, but the structural floor underneath them isn’t checked anywhere.

Headline catch

react relies on a ~600-entry, append-only JSON registry (scripts/error-codes/codes.json) plus a single source of truth (packages/shared/ReactVersion.js) that propagates across 3 per-package version fields — both extant patterns in production JS monorepos and both currently enforced by hand-rolled node scripts that alint replaces structurally today (codes.json shape) and that surface the recurring cross_file_value_equals (now v0.10 ship-target — saturated at 10 sources) and registry_append_only (v0.10 design candidate — react remains the sole source) rule kinds.

Real findings against the live tree, none of which surface from running eslint / prettier / flow:

Where alint earns its keep here

The structural floor under react’s well-evolved tooling: alint declares the per-package layout, codes.json shape, version-source shape, in-tree-eslint-plugin loading invariants, workflow-naming conventions, and Yarn-classic pinning — exactly the conventions extant only as oral history and review etiquette today.

react is the second-language data point for cross_file_value_equals — the same shape surfaced by airflow, tokio, clap, and uv on the Rust side, now demand-validated for the JS workspace world. react is also the first-of-kind (and still only) data point for registry_append_only — the codes.json append-only invariant is a clean abstraction over i18n string registries, feature-flag registries, API endpoint maps, error-code maps that any production app accumulates.

Use as evidence on alint.org/examples that structural drift exists even at the most evolved end of the JS monorepo spectrum — and that the cross-file value-equality + registry-shape primitives are recurring patterns, not one-off concerns.

Future story angles

The factual engineering writeup (tooling inventory, mapping table, gap catalogue, validation status footer) lives in the public alint repo at github.com/asamarts/alint/tree/main/examples/facebook-react/README.md.