Modifier une base de code à plusieurs paquets sans casser ce qui marche déjà

## Avant de modifier, identifier le paquet responsable et ses règles Avant toute modification, identifiez la racine du dépôt, le paquet ou le sous-système responsable du comportement ainsi que les instructions applicables aux contributeurs situées au plus près de la zone concernée. - Orientez le travail vers le plus petit périmètre approprié. - Lisez les références locales sur l'architecture, les conventions, la compilation et les tests nécessaires à ce périmètre. - Utilisez une recherche ciblée pour un symbole unique et un graphe de dépendances disponible pour les appelants répartis entre plusieurs fichiers, les imports, l'impact d'un renommage ou un large rayon de modification. - Confirmez les versions de l'environnement d'exécution et du gestionnaire de paquets, les définitions de l'espace de travail et les prérequis de compilation à partir de la configuration placée sous gestion de versions. - Traitez les fichiers d'instructions liés ou générés comme des vues de la source de référence qu'ils déclarent ; ne modifiez que le fichier source. Si les instructions se contredisent ou si la responsabilité n'est pas claire, arrêtez-vous avant d'écrire et indiquez précisément le conflit. Ne modifiez aucun paquet sans rapport pendant l'enquête. ## Garder le comportement et les noms publics actuels, et respecter l'architecture Évitez de perturber les utilisateurs existants. Ne modifiez aucune valeur par défaut et ne retirez aucun nom public, sauf si la modification approuvée l'exige explicitement. Maintenez les noms historiques en état de fonctionnement et accompagnez leur obsolescence d'une transition documentée et de tests portant sur le comportement antérieur. Respectez l'architecture déjà établie par le dépôt : - maintenez le comportement dans sa couche responsable ou sa limite d'extension ; - conservez l'équivalence entre les adaptateurs officiels lorsque le contrat central change ; - préservez la configuration en cascade et les contrats publics de personnalisation ; - neutralisez le contenu contrôlé par l'utilisateur et évitez de polluer l'espace de noms global ; - prenez en charge les exigences déclarées d'internationalisation et d'accessibilité ; et - privilégiez les utilitaires existants et un minimum de dépendances plutôt que des mécanismes parallèles. Si une modification incompatible est inévitable, signalez-la clairement, expliquez le contrat touché et proposez un parcours de migration. ## Faire la plus petite modification possible, avec tests et documentation Apportez la plus petite modification cohérente qui satisfait l'exigence. Respectez le style de code, de commentaires et de documentation établi par le paquet. Pour tout changement de comportement : 1. Ajoutez ou mettez à jour des tests unitaires ciblés. 2. Ajoutez les tests d'intégration, de navigateur ou de bout en bout appropriés lorsque le comportement traverse une limite. 3. Exécutez les compilations préalables requises avant les tests des paquets dépendants. 4. Exécutez les commandes ciblées d'analyse du code, des types, du style et des tests pour le périmètre concerné. 5. Mettez à jour les guides publics, les références d'API, les exemples, les notes de migration ou les entrées du journal des modifications lorsque les utilisateurs peuvent percevoir le changement. 6. Ne mettez à jour les instructions destinées aux contributeurs du périmètre que si la modification crée une convention, un emplacement, une contrainte ou un écueil récurrent et durable. Ne prétendez pas que le travail est terminé si les tests requis ou la documentation destinée aux utilisateurs manquent. Consignez tout test qui n'a pas pu être exécuté ainsi que la raison concrète. ## Demander l'approbation avant d'ajouter une dépendance et vérifier avant la publication Obtenez l'approbation de la personne responsable de la maintenance avant d'ajouter une dépendance tierce. Vérifiez les licences des dépendances directes et transitives, leur état de maintenance, les conséquences pour la sécurité, le coût du paquet produit ou d'exécution et si le dépôt offre déjà cette capacité. Respectez les conventions du dépôt pour les branches, les demandes de modification, les revues et le journal des modifications. Gardez l'historique des changements facile à examiner, évitez de réécrire l'historique partagé et séparez les travaux sans rapport. Pour un travail s'étendant sur plusieurs jours, conservez un point de contrôle visible au moyen de la méthode de collaboration approuvée par le dépôt. Avant la publication, confirmez que les tests de compatibilité couvrent l'ancien et le nouveau comportement, que la documentation requise est présente, que les artefacts générés sont à jour et que les variantes de paquet ou les adaptateurs prévus ont été testés. ## Indiquer les tests exécutés et les risques qui restent Renvoyez un rapport de vérification concis qui énumère : - le comportement modifié et son périmètre ; - les fichiers ou composants concernés ; - les tests, compilations et vérifications du code et des types exécutés, avec leurs résultats ; - les considérations de compatibilité et de sécurité ; - les mises à jour de la documentation ou du journal des modifications ; et - tout élément non exécuté, les risques restants et la prochaine action requise. Séparez les résultats vérifiés des hypothèses. Mettez en évidence toute modification incompatible ou vérification obligatoire inachevée avant les détails secondaires.