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

Canonical source: https://maguyva.ai/fr/languages/typescript

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

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.

## Aperçu du support

- Palier: Prise en charge de l’AST et des symboles
- Programmation
- Extensions: .cts, .d.ts, .mts, .spec.ts, .stories.ts, .test.ts, +1 de plus
- Analyse AST réelle pour une recherche consciente de la syntaxe et un contexte structurel.
- Les symboles nommés alimentent la recherche sémantique et le référencement croisé. La navigation par graphe est disponible lorsque l’extraction de relations est activée.
- Ce langage fournit des symboles et des relations à la recherche tenant compte du graphe ; les types d’arêtes pris en charge varient selon ses constructions natives.
- L’analyse AST et l’extraction de symboles sont toutes deux disponibles.

## 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é.

## 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 non qualifié 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é. Dans les fichiers TypeScript indexés, les tests, les stories et la configuration restent disponibles aux côtés du code applicatif, ce qui aide un agent à vérifier les exemples d'utilisation et la configuration avant de modifier un composant ou un service partagé.

## 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](/fr/languages/javascript). Si votre question est vraiment « l'agent peut-il maintenir ensemble le code applicatif et le contexte d'infrastructure ? », associez cette page à [Terraform](/fr/languages/terraform).

## 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. Dans les fichiers TypeScript indexés, les tests, les stories et la configuration restent disponibles comme contexte aux côtés du code applicatif.

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