This field test was against React.
The issue was React #33054:
https://github.com/facebook/react/issues/33054
The public PR is here:
https://github.com/facebook/react/pull/36709
The reported problem involved React Compiler and TypeScript non-null assertions.
The useful diagnostic boundary was:
TypeScript non-null assertion → compiler dependency/effect tracking → generated React behavior
That matters because React Compiler is not just transforming syntax.
It is making decisions about what values matter, where dependencies live, and how reactive scopes should be preserved through compilation.
The visible symptom was that a non-null assertion on an object could produce JavaScript that did not behave correctly after compilation.
The deeper issue was that the compiler preserved the non-null expression through HIR/codegen, but the non-null assertion was not being treated correctly as a value that still carried dependency and effect information.
In plain English:
the syntax was preserved, but the compiler’s understanding of the value’s reactive meaning drifted
That is a compiler truth-boundary failure.
The local/public repair is intentionally narrow.
It does not redesign React Compiler.
It does not broadly rewrite TypeScript handling.
It focuses on carrying non-null assertion dependencies through the compiler paths that need to understand them.
The patch updates compiler HIR visitors, dependency/effect handling, reactive scope pruning, codegen paths, and the relevant compiler fixture snapshots.
The goal is simple:
A non-null assertion should not erase the dependency-bearing or effect-bearing nature of the expression it wraps.
If a property read inside a callback depends on that expression, the compiler should preserve that relationship instead of treating the read as if it belonged to the wrong phase.
Validation listed on the PR includes formatting, linting, Flow, compiler snapshot build, and targeted compiler snapshot tests around non-null assertions.
Field Test #015
- Project: React
- Issue type: React Compiler / TypeScript non-null assertion behavior
- Boundary: TypeScript assertion syntax vs compiler dependency/effect tracking
- Result: public PR opened with compiler fixtures and snapshots
- Status: PR open; Meta CLA signed; review required
This field test matters because it moves Scarab into a core compiler semantics lane.
That is a different kind of boundary from app behavior, runtime resources, or infrastructure cache paths.
A compiler can preserve the shape of the code while still losing the meaning that code carried.
That is what makes compiler bugs subtle.
The output may look structurally plausible, but the compiler’s internal model may have stopped preserving the relationship that mattered.
In this case, the important question was not simply:
did the non-null assertion survive compilation?
The better question was:
did the dependency and effect meaning survive with it?
That is the kind of boundary Scarab is built to surface.
Not just where code changes.
Where meaning stops being preserved.
Top comments (0)