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

Đang mở
  • Có gì không ổn?
#64,611 10 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, typescript
Lĩnh vực
backend-api-design, developer-experience, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
112k
Fork
15.4k
Merge trung bình
3 ngày 1 giờ
Pull request đã merge (30 ngày)
136

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/TypeScript

Tất cả issue của microsoft/TypeScript

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.