In-memory virtual file overlay over LSP without faking `didOpen`

Offen
  • Stimmt etwas nicht?
#64,611 10 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go, typescript
Bereich
backend-api-design, developer-experience, tooling

Rechercherichtung

Start at the tsgo --lsp LSP server and its API session pipe, then compare the existing RequestFileSystem layered snapshots and runWithTemporaryFileUpdate behavior. Define how a virtual-file update and null clear should reach the VFS, and verify that generated .ngtypecheck.ts files are available to standard LSP requests without entering openClientFiles or requiring didOpen/didClose bookkeeping.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Suggestion
🔍 Search Terms

virtual file
setVirtualFile
RequestFileSystem
openClientFiles
didOpen didClose
temporary file update

✅ Viability Checklist
⭐ Suggestion

Add an overlay mechanism over the LSP server interface (tsgo --lsp) to push in-memory file contents directly into TS-Go's VFS (for example, a custom notification like ts/setVirtualFile with { path, content }, where null clears the overlay) without treating the files as client-opened documents.

📃 Motivating Example

We're using tsgo --lsp (with the API session pipe) as our backend diagnostics and type-checking engine for the Angular Language Service. To type-check templates, Angular generates synthetic in-memory TypeScript files containing Type Check Blocks (like app.component.ngtypecheck.ts) that TS-Go needs to type-check alongside user code.

Right now, we feed these into TS-Go by sending synthetic textDocument/didOpen and textDocument/didChange notifications. While that works, treating these files as client-opened documents pollutes openClientFiles, artificially bumps project retention ref-counts in ProjectService, and forces us to manage synthetic open/close lifecycle bookkeeping for files that aren't actually open in the editor.

The API client already has some support for layered VFS snapshots (RequestFileSystem with { kind: "layer" } and runWithTemporaryFileUpdate), but we don't have an equivalent way to push un-opened virtual files over the LSP connection.

An overlay notification over LSP (something like setVirtualFile(path, content | null)) would let us push our generated type-check files directly into TS-Go's VFS without openClientFiles pollution or open/close bookkeeping.

💻 Use Cases
  1. What do you want to use this for?
    To feed Angular's generated template type-checking code (.ngtypecheck.ts files containing Type Check Blocks) into TS-Go in memory.

We run tsgo --lsp as an out-of-proc semantic and diagnostics engine for both our dev server and our separate Angular Language Server. As users edit templates, we generate and update these synthetic .ngtypecheck.ts files so TS-Go can type-check them alongside the user's TypeScript code and answer semantic queries (hover, definition, completions). None of these synthetic files exist on disk, and they change frequently as templates are edited.

  1. What shortcomings exist with current approaches?
    Over LSP, the only current way to provide in-memory content is via textDocument/didOpen and textDocument/didChange. Because didOpen is built for user-facing editor buffers, using it for internal synthetic files causes a few headaches:
  • It registers the files in openClientFiles, adding unnecessary tracking overhead for files the user never opened.
  • It inflates ProjectService retention ref-counts, keeping configured projects alive longer than they should be or creating awkward project lifecycle behavior.
  • We have to build our own synthetic didOpen / didClose bookkeeping layer just to keep TS-Go's internal project state clean.

The API client recently added layered snapshot file systems (RequestFileSystem with { kind: "layer" } and runWithTemporaryFileUpdate), but that's scoped to immutable snapshots in the Node API client rather than a long-running tsgo --lsp server session answering standard LSP requests.

  1. What workarounds are you using in the meantime?
    In our language service facade, we currently fake the document lifecycle: we track synthetic version numbers, send textDocument/didOpen when generating a TCB, textDocument/didChange as the template updates, and send textDocument/didClose when components are removed or projects unload. It works functionally, but it's fragile and forces us to manage artificial lifecycle bookkeeping for purely ephemeral compiler artifacts.
Vorherrschende Sprache
Go
Sterne
112k
Forks
15.4k
Ø Merge
2 T. 21 Std.
Gemergte PRs (30 T.)
126

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/TypeScript

Alle Issues in microsoft/TypeScript

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.