[7.1 API] Equivalent of `BuilderProgram.getAllDependencies` / batched module resolution

Đang mở
  • Có gì không ổn?
#64,920 0 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

@jackeddisciple đang làm issue này rồi.

Từ ngày 23/10/2026.

  • #64942 của @jackeddisciple — đang mở

Đá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ệ
typescript
Lĩnh vực
api

Hướng nghiên cứu

Start by reading the Program API changes in #64247 and the builder/watch/solution-builder scope discussion in #64709, then compare the batched methods in #63904. The issue proposes either a server-side dependency graph method or batched module resolution, without choosing between them. Done means an API direction is agreed on and it addresses the per-import IPC cost and project-reference redirects described here.

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

Mô tả

🔍 Search Terms

getAllDependencies, dependency graph, getResolvedModule, batched, 7.1 API, typescript/sync, typescript/async

✅ Viability Checklist
⭐ Suggestion

In TypeScript ≤ 6, BuilderProgram.getAllDependencies(sourceFile) returned the transitive set of files a given source file depends on (module imports, /// <reference path>, type reference directives, and project-reference redirects).

With the 7.1 beta, builder/watch/solution-builder APIs are explicitly out of scope for stable (#64709), so there is no equivalent. The building blocks are mostly present (program.getSourceFileNames(), program.getSourceFile(), and the new program.getResolvedModule() / getResolvedTypeReferenceDirective() from #64247), but reconstructing the dependency graph requires one IPC round-trip per import per file, which gets expensive quickly on larger projects.

I'd like to request one (or both) of the following:

  1. A dependency-graph method on Program — e.g. program.getAllDependencies(sourceFile) or program.getDependencies(sourceFile) returning the direct/transitive dependency file names, computed server-side.
  2. A batched resolution method — e.g. program.getResolvedModules(sourceFile) returning all resolutions for a file in a single call, similar in spirit to the batched methods added in #63904. This would let consumers build the graph themselves with one call per file instead of one call per import.

Option 1 is the ergonomic fit for the old API; option 2 is a smaller primitive and can be used independently.

📃 Motivating Example

I use getAllDependencies in StrykerJS to identify inrelated files and use that to implement mutant grouping (a roughly 50% performance improvement over single mutant validation). Migrating to 7.1 currently means re-implementing the traversal client-side.

Current client-side reconstruction (7.1 beta) (using AI) 
import { API } from "typescript/sync";

function getAllDependencies(program: Program, rootFileName: string) {
  const seen = new Set<string>();
  const queue = [rootFileName];

  while (queue.length) {
    const fileName = queue.pop()!;
    if (seen.has(fileName)) continue;
    seen.add(fileName);

    const sf = program.getSourceFile(fileName);
    if (!sf) continue;

    // One round-trip per import
    for (const imp of sf.imports) {
      const r = program.getResolvedModule(sf, imp.text /*, mode */);
      if (r?.resolvedModule) queue.push(r.resolvedModule.resolvedFileName);
    }

    // One round-trip per type reference directive
    for (const ref of sf.typeReferenceDirectives) {
      const r = program.getResolvedTypeReferenceDirective(sf, ref.fileName);
      if (r?.resolvedTypeReferenceDirective?.resolvedFileName) {
        queue.push(r.resolvedTypeReferenceDirective.resolvedFileName);
      }
    }

    for (const ref of sf.referencedFiles) {
      queue.push(resolve(dirname(fileName), ref.fileName));
    }
  }

  seen.delete(rootFileName);
  return [...seen];
}

Issues with this approach:

  • Round-trip count scales with total import count, not file count.
  • Project-reference output redirects (handled by the old builder method) have to be reimplemented manually.
  • Resolution mode (ESNext vs CommonJS) must be derived client-side per import.
💻 Use Cases
  1. What do you want to use this for?

Generate a list of unrelated files so we can validate multiple mutants in a single type-check run.

  1. What shortcomings exist with current approaches?

Per-import IPC calls make the client-side traversal slow on large graphs, and project-reference redirects are easy to get subtly wrong.

  1. What workarounds are you using in the meantime?

The reconstruction above.

Ngôn ngữ chính
Go
Star
112k
Fork
15.4k
Merge trung bình
2 ngày 21 giờ
Pull request đã merge (30 ngày)
126

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.