Passer au contenu
cd /languages
Le choix par défaut du monorepoProgrammationSupport complet du graphe

Prise en charge de TypeScript dans Maguyva : un meilleur contexte pour les monorepos

Maguyva prend en charge TypeScript avec analyse AST et extraction de symboles, permettant aux agents IA de tracer interfaces, implémentations, packages partagés et code applicatif riche en JSX à travers les monorepos.

Pourquoi les pages TypeScript comptent

TypeScript est le langage où de nombreuses équipes attendent que la refactorisation assistée par IA paraisse enfin sûre. Le système de types aide, mais il n’élimine pas le vrai problème : packages partagés, DTO, clients générés, composants React, tests et code applicatif qui tirent tous sur les mêmes noms à travers un vaste dépôt.

Pour TypeScript, l’exigence dépasse un simple « il comprend la syntaxe ». L’agent doit suivre le contrat de la définition à l’implémentation, puis au rayon d’impact, avant de modifier un type partagé, un hook ou un client.

Ce que Maguyva extrait réellement en TypeScript

Maguyva extrait classes, méthodes, interfaces et alias de types à travers .ts, .mts, .cts, et les variantes de fichiers TypeScript courantes autour des tests et des stories. Les préfixes de membre sont normalisés, mais les identifiants qualifiés par classe sont préservés, ce qui aide quand un dépôt possède à la fois un nom d’utilitaire nu et une méthode rattachée à une classe partageant le même segment final.

JSX est traité comme un véritable signal structurel plutôt que comme du balisage isolé, et les attentes de symboles ignorent explicitement une bonne partie des chemins de test, de story et de configuration. Cela compte dans les monorepos, car sinon l’agent passe trop de temps à redécouvrir l’échafaudage plutôt que la véritable surface d’implémentation.

Flux de travail MCP utiles pour les dépôts TypeScript

Trois schémas de départ suffisent généralement :

  • Utilisez find_symbol quand vous connaissez déjà le nom de l’interface, de l’alias de type, du hook ou du service.
  • Utilisez dependency_search avant de modifier des types ou clients partagés susceptibles de se propager à travers les packages.
  • Utilisez structural_search quand vous avez besoin d’une forme de code, pas d’une correspondance de mot-clé, par exemple des schémas de composants ou de méthodes répétés.

Pour des questions conceptuelles comme « suivre le chemin de soumission du paiement », get_task_context constitue souvent un meilleur premier saut qu’une recherche brute.

Où cette page est la plus pertinente

Cette page est la plus utile pour les monorepos web et plateforme où TypeScript est la couche de coordination de plusieurs packages. Si votre dépôt inclut encore beaucoup de JS ancien, lisez le guide JavaScript. Si votre question est vraiment « l’agent peut-il maintenir ensemble le code applicatif et le contexte d’infrastructure ? », associez cette page à Terraform.

Idéal pour

  • >Les équipes produit et plateforme qui font tourner Next.js, des services Node, des packages partagés et de l'outillage dans un seul dépôt TypeScript.
  • >Les dépôts où interfaces, DTO, schémas et composants React évoluent ensemble tout en vivant dans des répertoires différents.
  • >Les équipes qui cherchent à donner aux agents IA un contexte sûr avant qu'ils ne touchent aux types partagés ou aux frontières de packages.

Workflows d'agent

  • >Suivre un type, une interface ou un composant depuis sa définition jusqu'aux chemins de code qui l'utilisent réellement.
  • >Comparer des implémentations entre packages avant de modifier un utilitaire partagé ou un contrat d'API.
  • >Cartographier le rayon d'impact probable de la modification d'un type, d'un utilitaire ou d'un module de service partagé.

Détails du moteur

  • >TypeScript extrait les classes, méthodes, interfaces et alias de type plutôt que d'aplatir le tout en symboles génériques.
  • >Les préfixes de membre sont retirés, mais les identifiants qualifiés par classe sont préservés, ce qui aide à distinguer `CheckoutService.create` d'un simple `create`.
  • >Les éléments JSX comptent comme des instanciations, et les chemins de test/story/config sont explicitement ignorés dans les attentes de symboles pour réduire le bruit.

Points d'entrée MCP utiles

  • find_symbol

    Commencez ici quand vous connaissez l'interface, l'alias de type, le hook ou le service partagé que vous voulez inspecter.

  • dependency_search

    Utilisez-le avant de changer un DTO ou un client partagé pour obtenir un rayon d'impact réaliste à travers les paquets.

  • structural_search

    Utilisez la recherche au niveau AST quand vous avez besoin d'un pattern, pas d'une correspondance de texte, par exemple des formes de composant ou de méthode répétées.