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

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

Maintainer antworten meist innerhalb von 1 Tag

@jackeddisciple arbeitet bereits daran.

Seit 23.10.2026.

  • #64942 von @jackeddisciple — offen

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
typescript
Bereich
api

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

🔍 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.

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.