Modifier une CLI de développement web faite de JavaScript et de code natif dans la bonne couche

## Trouver la couche responsable d’un comportement de la CLI et suivre les chemins global et local Avant toute modification, associez la demande au composant propriétaire du comportement : - les points d’entrée JavaScript ou TypeScript possèdent le comportement de haut niveau de la CLI locale et les exportations des paquets ; - les crates natifs possèdent le binaire global autonome, l’initialisation de l’environnement d’exécution, l’intégration au gestionnaire de paquets, les programmes d’installation, les migrations et les utilitaires de processus partagés ; - la liaison native possède le pont entre la CLI JavaScript locale et les implémentations natives des commandes ; - les paquets centraux exposent les surfaces intégrées de compilation, de test, de documentation et d’empaquetage ; - les outils du dépôt possèdent les registres locaux, les assistants de compilation, les fixtures et la prise en charge des publications ; - la documentation et les instructions de projet générées sont des produits distincts dont les sources diffèrent. Suivez séparément les voies globale et locale d’une commande lorsque toutes deux peuvent implémenter la même opération destinée à l’utilisateur. Une correction appliquée à une seule voie reste incomplète si l’autre demeure incohérente. Ne modifiez pas les instructions de projet générées lorsque la tâche concerne uniquement les instructions destinées aux contributeurs du dépôt. Préférez les documents canoniques d’architecture et de configuration aux explications copiées. ## Séparer les commandes intégrées des tâches du lanceur de tâches Distinguez les commandes intégrées de la chaîne d’outils de l’exécuteur de tâches. Une commande intégrée de test, de compilation, d’analyse statique ou de formatage peut appeler une implémentation incluse, tandis qu’une commande d’exécution lance un script de paquet ou une tâche configurée portant le même nom. Traitez les scripts de paquet comme des cibles d’exécution de premier ordre. N’utilisez une configuration explicite que lorsqu’une tâche nécessite des dépendances, une mise en cache, une configuration de commande, un suivi des entrées ou un suivi de l’environnement. Un nom de tâche ne doit avoir qu’un seul propriétaire. Ne définissez pas le même nom à la fois dans les scripts de paquet et dans la configuration des outils. Conservez la configuration des tâches dans le fichier canonique actuel ; ne réintroduisez pas de formats de configuration autonomes retirés. Maintenez les importations publiques de test sur la surface de paquet prise en charge et générez les adaptateurs de compatibilité depuis le script de compilation propriétaire. Ne recréez pas de paquets retirés et ne supposez pas qu’une dépendance externe appartient à l’espace de travail local. Avant de modifier le routage, examinez l’aide des commandes, les versions des outils inclus, les exportations des paquets et la documentation de tâches la plus proche. ## Choisir les tests minimaux adaptés au type de modification Utilisez le plus petit ensemble de validations couvrant le comportement modifié : - documentation ou instructions pour agents : vérifiez les chemins, commandes, liens et espaces référencés ; - comportement de la CLI JavaScript : exécutez la vérification du dépôt, les tests unitaires et les tests ciblés du paquet ; - comportement de la CLI native ou d’un crate : exécutez les vérifications, tests et analyses statiques natifs ; - présentation des commandes ou conception des interactions : exécutez des tests ciblés d’instantanés en pseudoterminal et examinez les différences ; - comportement de la CLI globale : recompilez et installez le binaire global local, puis vérifiez sa version et les commandes concernées ; - comportement de publication ou d’empaquetage : exécutez la compilation de publication ; - intégration avant fusion : initialisez la CLI, exécutez tous les tests et examinez l’état du dépôt. N’utilisez le mode de correction que lorsque les réécritures de formatage ou d’analyse statique font intentionnellement partie du périmètre. Pour une modification de comportement, localisez le test existant le plus proche avant de modifier le code et ajoutez la couverture dans la même zone. N’exécutez pas de vastes suites sans rapport avec une modification limitée à la documentation. N’affirmez pas non plus que le routage de la CLI est correct sur la seule base de tests unitaires lorsque la distribution des outils inclus intervient. ## Ajouter des tests de snapshot en pseudo-terminal qui tournent sous Unix et Windows Placez les nouveaux cas de ligne de commande et les parcours interactifs dans le banc d’instantanés en pseudoterminal du dépôt. Définissez chaque cas par une liste explicite d’arguments plutôt que par une chaîne shell. Utilisez les commandes auxiliaires du banc plutôt que des utilitaires système propres à une plateforme afin que la même fixture se comporte de façon identique sous Unix et Windows. Déclarez si le cas concerne la CLI locale, la CLI globale ou les deux ; les cas locaux nécessitent une distribution locale fraîchement compilée. Toute différence d’instantané doit provoquer un échec accompagné d’un diff révisable et produire un fichier de résultat candidat. Mettez les instantanés à jour uniquement par le mode d’enregistrement explicite, puis examinez le résultat enregistré comme du code avant de le consigner. Pour une modification de l’expérience des commandes, testez le comportement ciblé et sa transcription. Pour l’installation ou la migration, servez le checkout empaqueté par l’interface de registre local du dépôt au lieu de contourner le comportement réel du gestionnaire de paquets. Gardez explicites les jalons interactifs et les étapes de saisie afin qu’un échec identifie la phase qui a divergé. ## Suivre les règles de lint de chaque langage et ne modifier les fichiers générés que par leur générateur Pour le code natif, suivez les restrictions d’analyse statique, les assistants de sortie partagés, la configuration de l’environnement, la gestion des chemins et le style des commandes voisines. Pour TypeScript, utilisez le compilateur canonique, les assistants de sortie de terminal et la configuration des tâches du dépôt. Ne dupliquez pas les règles du langage dans les instructions aux contributeurs lorsque la source de référence est l’outil d’analyse, la configuration du compilateur ou une référence du code. Traitez les liaisons, adaptateurs, fichiers d’agents, distributions et résultats d’instantanés générés comme des artefacts ayant un propriétaire. Ne les modifiez que par leur générateur ou par le processus explicite d’acceptation des instantanés. Limitez le diff à la couche propriétaire demandée et laissez intacts les fichiers suivis ou non suivis sans rapport avec la tâche. Si un fichier généré change de manière inattendue, examinez la source ou le générateur au lieu de corriger directement le dérivé. Lors de la validation d’une CLI globale installée, utilisez le chemin d’initialisation documenté et confirmez la version résolue. Ne déduisez pas qu’une compilation de paquet a également actualisé le binaire installé. ## Déboguer en comparant le chemin natif global et le chemin JavaScript local Commencez par consigner les versions des composants inclus et par examiner l’aide générale ainsi que l’aide propre à chaque commande. Pour un défaut de routage, comparez la voie native globale avec la voie locale JavaScript et liaison. Pour un défaut de configuration, comparez l’extraction statique avec la résolution de secours en JavaScript. Pour un défaut du gestionnaire de paquets, examinez la surface des commandes, la couche d’installation et les instantanés de terminal correspondants. Pour un défaut de vérification, d’analyse statique, de formatage, de contrôle des types ou de test, validez la commande de bout en bout. Le routage des outils inclus peut laisser réussir des tests isolés de paquet tout en ignorant silencieusement la configuration de l’utilisateur. Lorsqu’un échec dépend de la variante locale ou globale, reproduisez explicitement les deux. Lorsqu’il dépend d’un résultat généré, recompilez le dérivé exact avant de conclure que la correction de la source est inefficace. Utilisez les instructions de navigation pour trouver les fichiers de référence ; ne laissez pas un guide concis pour agents remplacer la documentation détaillée d’architecture, de migration, de tâches ou d’instantanés.