Repository navigation
fix(vscode): resolve competing built-in TypeScript hover and diagnostics providers #196
Description
Activity
Confirmed on both macOS and Linux CI (run 34041160111, host evidence v-L06lg6). All 20 non-coexistence interfaces per grammar pass (80 total), and all 20 edit cases pass. Each of the four coexistence hosts combines a built-in
anyhover with the correct typed-sql property type. Draft PR #193 intentionally stays red.Next bounded work: define one supported owner for TypeScript hover/diagnostics/edit providers in typed-sql projects. Investigate supported per-workspace provider selection or an overlay integration with the built-in backend; do not invoke undocumented disable commands or silently disable the built-in extension. Preserve ordinary TypeScript support, cancellation, source mapping and unsaved edits. If explicit replacement is necessary, document the consent/reversal flow and verify it as a separate onboarding scenario. Do not label simultaneous-provider operation supported until the existing coexistence assertions pass.
Provider investigation: current VS Code source only disables its TS Server providers when both experimental.useTsgo is enabled and a recognized Microsoft native extension is present; setting the flag alone is not an ownership mechanism for third-party clients. Microsoft TypeScript 7 exposes registerContentMappers as an integration point, whereas its SDK resolver expects native TypeScript package executables. Do not spoof extension identities or package layouts to bypass this. A shared-provider integration versus an explicitly separate typed-sql editor profile is a material product choice; awaiting maintainer direction before changing provider ownership. Sources: https://github.com/microsoft/vscode/blob/main/extensions/typescript-language-features/src/extension.ts and https://github.com/microsoft/typescript-go/blob/main/_extension/src/contentMapperContributions.ts .
Microsoft integration is the maintainer-selected direction (2026-09-06), but the compatibility spike found a concrete upstream blocker. The exact pinned TypeScript 7.1.0-dev.20260824.1 rejects contentMappers registrations for both .ts and .tsx with TS100021, including with --runExternalCode enabled. Reproduction is preserved at artifacts/review/microsoft-integration-probe/tsconfig.json (local review artifacts, not committed). Current Microsoft source at 89d5d5b2849a0db0957065889ca58536fa6d2e4a also explicitly rejects built-in extensions in internal/tsoptions/tsconfigparsing.go. The exported extension API offers registerContentMappers and initializeAPIConnection; temporary API snapshots do not advance the shared language-server snapshot (internal/api/session.go). Therefore connecting the existing bridge to Microsoft does not make Microsoft editor providers see our transformed SQL types. No shared-provider mode has been shipped, no coexistence assertions weakened, and PR #193 remains draft. Next dependency: a supported Microsoft hook for mapped transformations of existing TypeScript/TSX documents, or an explicitly approved change of architecture. Upstream coordination has not been initiated.
Actual VS Code 1.134.0 coexistence matrix in PR #193 confirms that enabling vscode.typescript-language-features alongside typed-sql exposes conflicting hover types for inferred SQL rows. All four grammars pass isolated baseline/extended/edit scenarios; coexistence is a separate product boundary, not a grammar inference failure. Establish supported provider ownership without silently disabling user extensions or weakening assertions. Verify ordinary TypeScript plus SQL hover, diagnostics and edits with both extensions installed. Related #155. Evidence: host run v-ZnJzo6.