Modifier un grand monorepo typé sans casser les autres paquets

## Trouver le paquet responsable avant de modifier le code Partez de la racine du dépôt et identifiez le paquet responsable du comportement demandé. - Distinguez les bibliothèques centrales, les intégrations aux frameworks, les applications déployables, les exemples et les outils internes. - Lisez le guide de la racine et le guide de paquet le plus proche ; le guide le plus spécifique régit le comportement du paquet. - Confirmez l'environnement d'exécution fixé, le gestionnaire de paquets, l'organisation de l'espace de travail et la construction préalable avant d'exécuter des commandes de développement. - Ne supposez pas qu'un serveur de développement existe à la racine. Démarrez le paquet responsable ou utilisez le filtre d'espace de travail qui inclut ses dépendances en amont. - Avant de modifier un consommateur, remontez les types, les utilitaires, les styles et les ressources générées partagés jusqu'à leur paquet canonique. - Limitez la modification au plus petit paquet responsable, sauf si le contrat public s'étend réellement sur plusieurs paquets. ## Respecter les règles de construction et de dépendances de chaque paquet Choisissez le parcours de construction adapté au paquet au lieu d'imposer un seul outil à l'ensemble de l'espace de travail. - Utilisez un processus orienté compilation pour les bibliothèques purement typées et un outil de regroupement de composants pour les paquets d'interface. - Externalisez les dépendances dans la sortie de la bibliothèque ; utilisez une construction autonome explicite uniquement lorsque le livrable doit regrouper ses dépendances d'exécution. - Conservez les dépendances internes dans le protocole de l'espace de travail et obtenez les versions tierces partagées depuis le catalogue central des versions. - Importez les types partagés depuis leurs points d'entrée documentés, plutôt que depuis une racine de paquet trop générale. - Lorsqu'un paquet publie plusieurs formats, vérifiez chaque sortie déclarée et ses déclarations de types. - Considérez la configuration de construction, les fichiers de verrouillage, les paramètres partagés du compilateur et les catalogues de l'espace de travail comme des fichiers à large incidence qui exigent une validation plus étendue. ## Réutiliser les utilitaires communs avant d'écrire du code Recherchez dans le paquet commun de fonctions auxiliaires avant d'écrire un nouvel utilitaire. Vérifiez les fonctions auxiliaires existantes pour les tableaux, les objets, les chaînes, les URL, HTTP, JSON, Markdown, les erreurs, les fichiers, les files d'attente, le formatage, les expressions régulières et les tests. Réutilisez directement une fonction adaptée. N'ajoutez une nouvelle fonction au paquet commun que lorsqu'aucun comportement existant ne convient et que plusieurs consommateurs peuvent utiliser la nouvelle abstraction. Ne créez pas de quasi-doublons dans les paquets fonctionnels. Si le comportement existant est proche, mais pas exact, comparez les contrats, les cas limites, l'incidence sur le regroupement et les sites d'appel avant de décider de l'étendre ou de conserver une fonction locale propre au domaine. ## Éviter `any` et typer les fonctions et les props des composants Écrivez du code qui préserve l'utilité de l'inférence tout en rendant les contrats publics explicites. - Préférez les alias de types et les unions de littéraux de chaînes aux interfaces et aux énumérations lorsque la norme de la base de code le prévoit. - Donnez aux fonctions des types de retour explicites, utilisez `unknown` plutôt que `any`, marquez les importations réservées aux types et privilégiez les liaisons immuables. - Conservez des importations directes ; évitez les fichiers d'agrégation, sauf aux points d'entrée de paquets créés délibérément, et évitez les réexportations avec caractères génériques. - Ne masquez jamais les erreurs de types de manière globale. Utilisez une directive d'erreur attendue uniquement avec une justification prouvant que l'erreur est intentionnelle. - Traitez chaque promesse et ne marquez une fonction comme asynchrone que si elle attend une opération. - Dans les fichiers de composants, typez les propriétés et les événements, définissez les valeurs par défaut par déstructuration, déplacez la logique de gabarit non triviale vers des valeurs calculées et respectez l'ordre de configuration établi. - Rédigez les commentaires et la documentation d'API pour expliquer pourquoi une contrainte existe, et non pour reformuler le code. ## Tester d'abord le paquet concerné, pas tout le dépôt Exécutez le plus petit périmètre de tests qui démontre la modification. 1. Placez les tests unitaires à côté de leur code source et nommez la suite de premier niveau d'après le fichier. 2. Préférez les assertions comportementales et les fonctions pures ; réduisez les simulations au minimum et évitez de tester la structure du balisage ou les détails de style lorsque le comportement de l'utilisateur constitue le contrat. 3. Exécutez une fois le paquet concerné avec un filtre de chemin explicite. Utilisez le mode de surveillance uniquement pendant le développement actif. 4. Exécutez des tests d'intégration pour les adaptateurs modifiés et des tests de bout en bout pour les parcours utilisateur concernés. 5. Démarrez les services de test locaux requis et attendez qu'ils soient prêts avant les tests qui en dépendent ; les tests unitaires ne doivent pas utiliser le réseau réel. 6. Exécutez la suite complète du monorepo uniquement pour une vérification finale d'intégration intentionnelle ou une modification étendue d'un contrat commun. Traitez séparément les échecs préexistants sans rapport avec la modification : reproduisez-les hors du périmètre de la modification, signalez-les comme tels et ne les présentez à tort ni comme une réussite de l'environnement ni comme un échec causé par la modification. ## Passer le lint sur les fichiers modifiés et vérifier les types des paquets touchés Déterminez l'ensemble des fichiers modifiés et appliquez chaque outil uniquement à la syntaxe dont il est responsable. - Exécutez l'outil d'analyse statique et le formateur du langage typé sur les fichiers typés modifiés. - Exécutez l'outil d'analyse des composants et le formateur général sur les fichiers modifiés de composants, de documentation, de données, de styles et de configuration. - Vérifiez les types de chaque paquet concerné au moyen de son script d'espace de travail. - Recherchez les exportations, les fichiers et les dépendances inutilisés avant d'ouvrir ou de mettre à jour une revue. - Exigez que tous les contrôles pertinents d'analyse, de formatage, de types, de tests et de code inutilisé réussissent sans erreur. N'utilisez pas une commande visant tout le dépôt lorsqu'un filtre de paquet fournit un signal plus fort avec moins de bruit sans rapport. Étendez la validation lorsque la configuration fondamentale change ou que l'analyse des dépendances révèle plusieurs consommateurs en aval. ## Écrire les titres de revue au format type(scope) et ajouter un changeset Utilisez une branche dédiée et des descriptions conventionnelles de la modification au présent, avec le périmètre du paquet concerné. - Donnez aux titres des revues la forme sémantique `type(scope): subject` en utilisant un type de modification autorisé. - Placez les références aux tickets et aux problèmes dans la description de la revue avec le mot-clé de clôture ou de non-clôture approprié ; n'enfouissez pas dans les commentaires les identifiants de suivi requis. - Ajoutez une section dédiée aux tickets lorsque des liens de suivi sont fournis. - Pour les modifications publiables de paquets, d'intégrations ou d'applications, vérifiez l'état des notes de version et ajoutez un jeu de modifications de niveau patch ou minor lorsque la version doit avancer. N'introduisez pas de hausse major par le processus habituel. - Gardez les solutions temporaires visibles au moyen d'un TODO et expliquez la condition permettant de les retirer. - Ne créez jamais de commit contenant des échecs connus d'analyse, de types, de tests ou d'exportations inutilisées. ## Vérifier les changements d'interface, captures à l'appui, dans l'environnement d'essai qui les montre Construisez les paquets en amont, puis choisissez l'environnement d'essai qui expose le plus directement le comportement modifié. - Utilisez le catalogue de composants pour les commandes de base, la surface de documentation pour le rendu et la navigation, et la surface client pour l'édition, l'authentification, les requêtes et les réponses. - Vérifiez les surfaces secondaires lorsque des composants partagés, des thèmes, le rendu de la syntaxe ou des icônes se propagent à plusieurs produits. - Réalisez des captures avant et après pour l'interface modifiée, des captures en contexte pour le nouveau comportement et un court enregistrement pour les interactions. - Donnez des noms descriptifs aux artefacts et intégrez les preuves dans une section visuelle dédiée de la description de la revue. - Si une modification touche plusieurs surfaces ou mises en page, capturez chaque résultat sensiblement différent au lieu de traiter une seule capture comme une preuve universelle. Les artefacts visuels complètent les tests automatisés ; ils ne remplacent pas les assertions comportementales, les contrôles d'accessibilité ni la validation des types. ## Employer les termes exacts du projet et ne signaler que les vérifications faites Utilisez systématiquement le glossaire du projet dans le code, la documentation, les tests et le texte des revues. Distinguez un format de protocole d'une description d'API, un schéma de données d'un document, le déréférencement de la résolution et le regroupement de ces deux dernières opérations. Avant de terminer : - examinez le diff final et confirmez que chaque fichier modifié appartient au périmètre prévu ; - vérifiez, selon le cas, la construction, les tests, l'analyse, le formatage, les types, la recherche de code inutilisé et les preuves visuelles ; - confirmez que les points d'entrée des paquets, les catalogues de dépendances et les jeux de modifications correspondent à l'implémentation ; - répertoriez tout contrôle qui n'a pas pu être exécuté et conservez la preuve exacte de son échec ; - ne prétendez pas disposer d'un résultat pour l'ensemble du monorepo lorsqu'un contrôle limité à un paquet a seulement été exécuté. Indiquez les paquets concernés, les commandes exécutées, les résultats directs, les risques résiduels et tout travail intentionnellement reporté.