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

Aperta
  • Qualcosa non va?
#64,611 10 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, typescript
Ambito
backend-api-design, developer-experience, tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
112k
Fork
15.4k
Merge medio
2g 21h
PR unite (30g)
126

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/TypeScript

Tutte le issue di microsoft/TypeScript

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.