Zum Inhalt springen
cd /languages
Monorepo-StandardProgrammierungVollständiger Graph-Support

TypeScript-Unterstützung in Maguyva: Besserer Kontext für Monorepos

Maguyva unterstützt TypeScript mit AST-Parsing und Symbolextraktion, damit KI-Agents Interfaces, Implementierungen, gemeinsam genutzte Packages und JSX-lastigen Anwendungscode über Monorepos hinweg nachverfolgen können.

Warum TypeScript-Seiten zählen

TypeScript ist die Sprache, bei der viele Teams erwarten, dass sich KI-gestütztes Refactoring endlich sicher anfühlt. Das Typsystem hilft, beseitigt aber nicht das eigentliche Problem: gemeinsam genutzte Packages, DTOs, generierte Clients, React-Komponenten, Tests und App-Code ziehen alle an denselben Namen in einem großen Repo.

Bei TypeScript liegt der Maßstab höher als „versteht Syntax“. Der Agent muss den Contract von der Definition über die Implementierung bis zum Impact-Radius verfolgen können, bevor er einen gemeinsam genutzten Typ, Hook oder Client bearbeitet.

Was Maguyva in TypeScript tatsächlich extrahiert

Maguyva extrahiert Klassen, Methoden, Interfaces und Type Aliases über .ts, .mts, .cts und die gängigen TypeScript-Dateivarianten rund um Tests und Stories. Member-Präfixe werden normalisiert, klassenqualifizierte Identifier bleiben jedoch erhalten — das hilft, wenn ein Repo sowohl einen nackten Helper-Namen als auch eine klassengebundene Methode mit demselben letzten Segment hat.

JSX wird als echtes strukturelles Signal behandelt statt als loses Markup, und die Symbol-Erwartungen überspringen ausdrücklich viele Test-, Story- und Config-Pfade. Das zählt in Monorepos, weil der Agent sonst zu viel Zeit damit verbringt, Scaffolding statt der eigentlichen Implementierungsoberfläche wiederzuentdecken.

Nützliche MCP-Workflows für TypeScript-Repos

Drei Einstiegsmuster reichen meist aus:

  • Nutze find_symbol, wenn du bereits das Interface, den Type Alias, Hook oder Service-Namen kennst.
  • Nutze dependency_search, bevor gemeinsam genutzte Typen oder Clients geändert werden, die über mehrere Packages verzweigen könnten.
  • Nutze structural_search, wenn du eine Codeform brauchst, keinen Keyword-Treffer — zum Beispiel wiederkehrende Komponenten- oder Methodenmuster.

Für konzeptionelle Fragen wie „verfolge den Checkout-Submission-Pfad“ ist get_task_context oft der bessere erste Schritt als eine rohe Suche.

Wo diese Seite am relevantesten ist

Diese Seite ist am stärksten für Web- und Plattform-Monorepos, in denen TypeScript die Koordinationsschicht für mehrere Packages ist. Wenn dein Repo noch viel älteres JS enthält, lies den JavaScript-Guide. Wenn deine eigentliche Frage lautet „kann der Agent App-Code und Infra-Kontext zusammen im Blick behalten?“, kombiniere das mit Terraform.

Am besten geeignet

  • >Produkt- und Plattform-Teams, die Next.js, Node-Services, gemeinsam genutzte Packages und Tooling in einem einzigen TypeScript-Repo betreiben.
  • >Repos, in denen sich Interfaces, DTOs, Schemas und React-Komponenten gemeinsam weiterentwickeln, aber in unterschiedlichen Verzeichnissen liegen.
  • >Teams, die KI-Agents sicheren Kontext geben wollen, bevor diese gemeinsam genutzte Typen oder Package-Grenzen anfassen.

Agentenabläufe

  • >Einem Typ, Interface oder einer Komponente von der Definition bis zu den Codepfaden folgen, die ihn tatsächlich verwenden.
  • >Implementierungen über Packages hinweg vergleichen, bevor ein gemeinsam genutzter Helper oder API-Contract geändert wird.
  • >Den wahrscheinlichen Blast Radius für die Änderung eines gemeinsam genutzten Typs, Utilitys oder Service-Moduls abbilden.

Engine-Einordnung

  • >TypeScript extrahiert Klassen, Methoden, Interfaces und Type-Aliase, statt alles zu generischen Symbolen zu verflachen.
  • >Member-Präfixe werden entfernt, aber klassenqualifizierte Bezeichner bleiben erhalten, was hilft, `CheckoutService.create` von einem bloßen `create` zu unterscheiden.
  • >JSX-Elemente zählen als Instanziierungen, und Test-/Story-/Config-Pfade werden in den Symbol-Erwartungen explizit übersprungen, um Rauschen zu reduzieren.

Nützliche MCP-Einstiegspunkte

  • find_symbol

    Fang hier an, wenn du das gemeinsam genutzte Interface, den Type-Alias, den Hook oder Service kennst, den du untersuchen willst.

  • dependency_search

    Nutz es, bevor du ein gemeinsam genutztes DTO oder einen Client änderst, um einen realistischen Impact-Radius über Packages hinweg zu bekommen.

  • structural_search

    Nutz AST-Level-Suche, wenn du ein Muster brauchst, keinen String-Match, etwa wiederkehrende Komponenten- oder Methoden-Formen.