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

Ouverte
  • Quelque chose ne va pas ?
#64,611 10 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
go, typescript
Domaine
backend-api-design, developer-experience, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Go
Étoiles
112k
Forks
15.4k
Merge moyen
2 j 21 h
PR mergées (30 j)
126

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/TypeScript

Toutes les issues de microsoft/TypeScript

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.