This field test was against Next.js.
The issue was Next.js #94450:
https://github.com/vercel/next.js/issues/94450
The reported problem involved production browser source maps when React Compiler and Turbopack were involved.
The visible symptom was that the final browser source map could expose transformed compiler output instead of preserving the original client source content.
That matters because source maps are not just debugging extras. They are provenance artifacts. They tell the developer what source the browser output came from.
If a source map claims to represent a source file but its sourcesContent contains compiler-transformed output instead of the original file content, then the debugging artifact has drifted from the source truth it is supposed to preserve.
The useful diagnostic boundary was:
original client source → transform source map → Turbopack source-map composition → final browser chunk map
The important proof was that the Babel/React Compiler transform itself could produce a source map whose sourcesContent still represented the original client file.
So the loss was not simply:
React Compiler changed the code
The sharper issue was:
the browser source-map composition path was not preserving original source authority all the way into the final artifact
That made the repair lane much narrower.
The local repair candidate has two parts:
- Preserve the original loader input source in the Babel loader transform map.
- Fill missing source-map file provenance from the origin path when an incoming transform map omits it, so Turbopack has enough identity information to match the transform map back to the generated intermediate file during composition.
The goal is not to rewrite source-map behavior broadly. It is not to patch the final browser map after the fact. It is to preserve source authority at the point where the transform map is composed into the browser artifact.
A regression fixture was added around a React Compiler client component with an original source marker.
The test asserts that the production browser source map keeps the original client source content and does not expose compiler-transformed markers such as React Compiler runtime output.
Local validation passed for the focused browser source-map proof, the relevant Turbopack source-map utility test, Rust formatting on the touched file, and diff hygiene.
Nothing has been opened publicly yet.
Field Test #012
- Project: Next.js
- Issue type: production browser source-map provenance
- Boundary: transform source-map authority vs final browser artifact composition
- Result: narrow local repair candidate and regression fixture
- Status: local proof prepared; no public PR or comment opened yet
The important part of this field test is that the bug was not treated as a vague “source maps are wrong” problem.
That would be too broad.
The useful question was:
where did original source truth stop being preserved?
The answer was not at the first transform. The transform could still produce a map with original source content. The break appeared later, when the browser artifact was composed.
That is the kind of distinction Scarab is built to surface.
A broad patch might try to rewrite source-map handling, disable fallback content, or adjust the final output after the fact.
A better repair looks for the exact boundary where provenance is lost.
In this case, the source map needed enough identity information to carry original-file authority through composition.
That is why this field test matters.
It is another example of software truth drift in a major framework system.
Not AI drift specifically. Not a simple runtime crash. Not a failing UI.
This was artifact truth.
The source file had one truth. The transform map preserved it. The final browser source map drifted from it.
Scarab’s role is to identify that kind of boundary before repair begins.
Because once the boundary is clear, the repair can be much smaller than the symptom suggests.
Top comments (0)