Modifier et tester du code dans un grand monorepo à nombreux paquets

## Repérer les paquets et les points d'entrée avant de modifier - Identifiez l'organisation de l'espace de travail, les paquets publiés, les composants natifs, les suites de tests, les exemples, la documentation et les scripts de maintenance. - Repérez l'arborescence source du paquet principal, la sortie compilée, les points d'entrée de ligne de commande, les points d'entrée du serveur et le point d'entrée de la compilation. - Suivez le point d'entrée pertinent avant de modifier le comportement ; ne déduisez pas la responsabilité à partir du seul nom d'un fichier. - Avant de modifier un fichier imbriqué, lisez tous les `README.md` applicables depuis la racine du dépôt jusqu'au répertoire cible. - Traitez la sortie générée et les répertoires de dépendances uniquement comme des preuves destinées aux recherches. Modifiez leur source ou leur générateur au lieu de modifier directement les fichiers générés. ## Garder la compilation à jour et choisir une compilation ciblée ou complète - Après un changement de branche ou l'initialisation d'un espace de travail dont l'état est incertain, exécutez la compilation d'amorçage complète afin d'actualiser les sorties des paquets dépendants. - Pour un travail itératif sur le code source ou les tests d'intégration, démarrez la compilation du paquet en mode surveillance avant toute modification, sauf si elle est déjà en cours. - Une modification limitée à la documentation, une enquête en lecture seule ou une analyse limitée à la CI peut omettre le mode surveillance, mais consignez-en la raison. - Utilisez la compilation ciblée du paquet lorsque les modifications restent dans un seul paquet. Utilisez la compilation complète lorsque le travail traverse plusieurs paquets ou modifie du code natif. - Pour les erreurs de type, préférez la vérification de types dédiée à une compilation complète lorsqu'elle fournit des preuves équivalentes. - Arrêtez tout processus de surveillance que vous avez démarré une fois la tâche terminée. ## Choisir les tests adaptés au mode développement ou production - Choisissez la commande de test qui correspond exactement au comportement de développement ou de production et à l'implémentation prévue du bundler ou de l'environnement d'exécution. - Recompilez le code source affecté avant d'exécuter les tests d'intégration ; une sortie compilée obsolète invalide le résultat. - Exécutez d'abord le fichier de test ou le motif de nom pertinent le plus ciblé, puis élargissez uniquement lorsque l'échec ou la surface de modification l'exige. - Reproduisez la CI avec les mêmes commande, mode, indicateurs de fonctionnalité et noms de variables d'environnement. De petites différences de mode peuvent modifier la résolution et les instantanés. - Ne remplacez pas un test d'intégration par un test unitaire commode lorsque l'affirmation porte sur la résolution des paquets, le regroupement, le démarrage ou le comportement du navigateur. - Lorsque des indicateurs de fonctionnalité activent implicitement un comportement, testez la suite normale avec cet indicateur plutôt que de vous fier uniquement aux anciennes suites dédiées. ## Écrire des tests qui attendent une condition plutôt qu'un délai fixe - Utilisez le générateur de tests du dépôt, y compris ses arguments non interactifs, afin que les fixtures et la configuration du harnais respectent les conventions locales. - Préférez les auxiliaires de nouvelle tentative fondés sur des conditions et accompagnés d'assertions aux attentes fixes. Les délais fixes sont lents et restent sujets aux conditions de concurrence. - Remplacez les auxiliaires d'interrogation obsolètes par le modèle pris en charge de nouvelle tentative avec assertion. - Préférez de véritables répertoires de fixtures aux grandes tables de fichiers en ligne afin que les tests ressemblent à des projets réels et restent faciles à maintenir. - Pour les tests propres à un mode, exécutez la garde de mode avant de démarrer manuellement un serveur lorsque le harnais exige un démarrage différé. - Contrôlez la prélecture et l'état de navigation dans la limite de synchronisation du test ; évitez les actions d'historique qui restaurent un état mis en cache et déclenchent un travail non maîtrisé. ## Enregistrer la sortie des tests et des compilations au lieu de les relancer - Capturez une fois la sortie complète d'un test ou d'une compilation, puis recherchez et résumez la sortie enregistrée au lieu de réexécuter la même suite avec différents filtres. - Pour les fichiers de plus de 500 lignes environ, recherchez d'abord les symboles pertinents et ne lisez que les plages environnantes. - Recherchez dans les répertoires générés uniquement lorsque cela est nécessaire pour confirmer le comportement produit ; ne les parcourez pas comme source principale. - Regroupez les modifications liées avant d'exécuter la compilation suivante et utilisez la vérification la plus rapide qui démontre l'hypothèse actuelle. - Mettez en cache les réponses d'état distantes pendant une enquête et analysez la réponse enregistrée sous plusieurs angles au lieu de la récupérer à plusieurs reprises. - Conservez la sortie exacte de l'échec, la commande, le mode et l'environnement comme preuves pour l'étape de diagnostic suivante. ## Reproduire les échecs de CI et les corriger avant les commentaires de révision - Utilisez l'outil d'analyse d'état du dépôt lorsqu'il existe et déterminez si la branche actuelle ou une demande de modification explicite est examinée. - Traitez les échecs bloquants dans cet ordre, sauf si les preuves imposent le contraire : compilation, formatage ou lint, types, puis tests. - Considérez les échecs comme réels jusqu'à preuve du contraire. Un comportement instable connu fournit un contexte d'enquête, pas l'autorisation d'écarter un échec. - Reproduisez avec le même mode de CI et les mêmes indicateurs d'environnement, surtout lorsque différents bundlers ou chemins d'exécution sont disponibles. - Pour les échecs de résolution de modules ou de graphe de compilation, exécutez la commande d'intégration normale propre au mode afin d'exercer le graphe réel des paquets. - Séparez les échecs de CI des commentaires de révision, résolvez d'abord les preuves d'exécution bloquantes et conservez une trace concise de ce qui a été reproduit. ## Relier les indicateurs de fonctionnalité à la compilation et à l'exécution - Ajoutez un nouvel indicateur de fonctionnalité à son type public, à son schéma de validation et à son point d'injection lors de la compilation lorsque du code regroupé par l'utilisateur l'utilise. - Si le code d'exécution précompilé utilise l'indicateur, raccordez également la valeur d'exécution à chaque chemin pertinent de serveur ou de processus de travail. - Ne supposez pas que l'injection lors de la compilation destinée au code utilisateur contrôle les composants internes précompilés de l'environnement d'exécution. - Conservez les chargements conditionnels de modules dans des branches `if` / `else` évaluées lors de la compilation afin que l'élimination du code mort puisse retirer les dépendances inaccessibles. - Dans les environnements d'exécution restreints, forcez à `false` les indicateurs qui protègent les importations de plateformes non prises en charge. - Conservez les importations propres à l'environnement d'exécution dans leur module d'entrée désigné et exposez le comportement requis par la façade publique de ce module. - Utilisez un signal d'exécution dédié pour distinguer un serveur de développement actif d'une compilation de débogage ; une étiquette d'environnement générique peut décrire les deux. - Signalez pour révision de sécurité tout nouvel en-tête de requête entrante non standard, sauf si la couche d'entrée le retire ou l'authentifie. ## Garder les secrets hors des journaux et s'arrêter si l'authentification échoue - Traitez les valeurs des variables d'environnement comme sensibles, sauf s'il s'agit d'indicateurs documentés du mode test. - N'imprimez, ne collez, n'intégrez à aucun commit et ne placez jamais de jetons, clés, cookies ou valeurs secrètes dans des journaux partagés, du texte de révision ou des exemples. - Reproduisez les noms et les modes des variables de CI sans intégrer directement leurs valeurs. Si un secret requis manque, arrêtez-vous et demandez-le par le canal approuvé. - Utilisez des espaces réservés pour documenter la configuration et n'ajoutez jamais les fichiers secrets locaux à un commit. - Si l'authentification du contrôle de versions échoue parce qu'un agent de signature, un fournisseur de clés ou un identifiant protégé par du matériel est indisponible, arrêtez-vous et demandez à l'utilisateur de le déverrouiller. - Ne modifiez ni les protocoles ni les adresses distantes, ne répétez pas l'opération qui a échoué et ne tentez pas de contournement d'authentification sans approbation explicite. ## Vérifier les droits avant de publier une demande de changement ou un commentaire - Avant de créer ou de modifier une demande de changement, un ticket, une discussion ou un commentaire distant, déterminez si la contribution provient d'une branche interne ou d'un fork externe. - Vérifiez la politique de contribution du dépôt et l'autorisation de l'utilisateur avant d'écrire en son nom. - Si l'autorisation est insuffisante, ne vous faites pas passer pour un responsable de maintenance et ne publiez pas l'intégralité du contenu distant. Fournissez des faits techniques, révisez le texte rédigé par l'utilisateur et indiquez le chemin de soumission contrôlé par celui-ci. - Appliquez les exceptions documentées de manière restrictive et uniquement après avoir vérifié leurs conditions. - Conservez les nouvelles demandes de changement à l'état de brouillon, sauf si l'utilisateur décide explicitement qu'elles sont prêtes pour révision. - Les écritures distantes exigent un périmètre explicite ; l'analyse et la reproduction locales n'impliquent pas l'autorisation de publier. ## Découper le travail en petites étapes et vérifier chacune - Divisez une tâche importante en petites étapes dont les résultats peuvent être vérifiés indépendamment. - Vérifiez chaque étape avant de passer à la suivante avec la méthode adaptée à son risque : inspection, formatage, lint, types, tests unitaires, tests d'intégration, compilation ou observation de l'exécution. - Lorsque la bonne méthode de vérification n'est pas claire, demandez avant d'affirmer que l'étape est terminée. - Avant de créer un commit, exécutez sur les fichiers modifiés la même configuration de formateur et de linter que celle utilisée par le hook de commit du dépôt. - Examinez le diff final pour détecter les modifications sans rapport, le bruit généré, le contenu secret et les tests ou la documentation manquants. - Ne signalez pas l'achèvement sans nommer les preuves qui étayent le comportement modifié. ## Repérer les binaires natifs obsolètes et les instantanés qui ne correspondent pas - La recherche dans les cartes de sources peut nécessiter un indicateur d'exécution explicite, et les chemins sources peuvent différer selon les compilateurs ; testez les formes de chemin connues. - Tenez compte du répertoire de travail actuel lorsque vous comparez les traces de pile des tests et de la production. - Après un changement de branche, soupçonnez des binaires natifs obsolètes lorsque le comportement contredit la source ; actualisez l'artefact géré par les dépendances par le chemin d'amorçage approuvé. - En cas d'erreur interne du compilateur, retirez uniquement le cache de compilation incrémentale affecté et réessayez une fois avant de faire remonter le problème. - Utilisez le formateur officiel pour le code en langage natif et préférez les importations ancrées à la racine du dépôt, sauf dans des modules de test en ligne au périmètre étroitement limité. - La sortie des instantanés peut varier selon les indicateurs et l'implémentation de l'environnement d'exécution ; actualisez donc les instantanés uniquement dans l'environnement exact utilisé par la tâche CI cible. - Dans les blocs de code de la documentation, recomptez les lignes affichées après les modifications et confirmez que chaque mise en évidence désigne l'instruction prévue.