This field test was against TypeScript.
The issue was TypeScript #63499:
https://github.com/microsoft/TypeScript/issues/63499
The reported problem involved auto-import suggestions and wildcard package.json exports.
The useful diagnostic boundary was:
package export declaration → resolver containment check → auto-import suggestion
That matters because auto-imports are not just editor convenience.
They are language-service decisions about what paths are valid to suggest to a developer.
If the language service offers an import path that escapes the package boundary, then the editor is presenting an invalid or unsafe source relationship as if it were legitimate.
The visible symptom was that wildcard package exports could produce an auto-import suggestion for a path that should have been rejected by containment rules.
The deeper issue was phase order.
Non-wildcard export targets already rejected invalid path segments like:
- ..
- .
- node_modules
But wildcard export targets could reach directory enumeration before the same containment check was applied.
In plain English:
one export path went through the boundary check before use, while another path could enumerate first and validate too late
That is a package-boundary authority failure.
The local repair candidate is intentionally narrow.
It does not redesign auto-imports.
It does not change package export semantics broadly.
It applies the existing invalid-target check before wildcard directory enumeration, so wildcard exports obey the same containment expectation before the language service searches for completion candidates.
A regression test was added to prove that an out-of-package declaration is not offered as an auto-import completion.
Validation passed locally:
- red proof failed before the resolver fix
- npx hereby runtests --tests=autoImportProvider passed with 78 passing
- npx hereby local passed
- npx hereby lint passed
- git diff --check passed
No public PR has been opened yet.
Field Test #016
- Project: TypeScript
- Issue type: language-service auto-import / package exports containment
- Boundary: package export target validity vs auto-import resolver enumeration
- Result: narrow local repair candidate and regression test
- Status: local proof prepared; public maintainer-direction comment recommended before PR
This field test matters because it sits inside the language-service layer.
The bug is not a runtime crash.
It is not a failed build.
It is not a UI rendering problem.
It is the editor/compiler tooling suggesting an import relationship that should not be treated as valid.
That is a different kind of software truth boundary.
A package declares what it exports.
The resolver decides what those declarations mean.
The language service turns that into developer-facing suggestions.
If the containment check happens too late in one path, the tool can present an invalid package relationship as if it were safe.
That is exactly the kind of boundary Scarab is built to surface:
not just whether the editor can find something,
but whether the thing it found is allowed to be treated as source truth.
Top comments (0)