Modifier une bibliothèque de composants d’interface et vérifier que rien ne casse

## Lancer les commandes depuis la racine du dépôt avec son gestionnaire de paquets Utilisez uniquement le gestionnaire de paquets et le style de commandes d’espace de travail déclarés par le dépôt. Exécutez les opérations limitées à un paquet au moyen du filtre d’espace de travail du gestionnaire depuis la racine, au lieu d’entrer dans les répertoires des paquets et d’appeler un autre outil. Installez des dépendances uniquement lorsque cela est nécessaire. Pendant l’itération, privilégiez la commande de compilation, de test, de lint ou de vérification des types ayant la portée de paquet la plus étroite possible, et réservez les compilations de l’ensemble du dépôt à la vérification de l’intégration ou de la publication. Conservez comme flux de travail distincts le développement de la documentation, les compilations des paquets, les compilations de la documentation, les tests unitaires, les tests sur navigateur, les tests de bout en bout, les tests de régression visuelle, le formatage, le lint et la vérification des types. ## Placer les nouveaux composants dans la zone expérimentale et garder les paquets internes privés Structurez la bibliothèque en composants principaux, système de styles, composants expérimentaux, icônes ou ressources, utilitaires partagés, abstraction du moteur de styles et paquets internes non publiés. Respectez la distinction entre les paquets publics et ceux qui existent uniquement pour prendre en charge l’espace de travail. Introduisez les composants nouveaux ou instables dans la zone expérimentale prévue avant de les promouvoir vers le paquet stable. Conservez les styles partagés et le comportement des thèmes dans la couche de styles au lieu de les dupliquer entre les composants. N’exposez pas les paquets internes par des points d’entrée publics et ne contournez pas l’abstraction configurée du moteur de styles au moyen d’hypothèses propres à une implémentation. ## Ranger les fichiers de chaque composant et n’importer que le nécessaire Respectez l’organisation des fichiers de composants du dépôt pour l’implémentation, les déclarations, les tests, les classes de style et les exportations publiques. Conservez chaque responsabilité dans le fichier qui en est propriétaire afin que la documentation des API, les tests et le tree-shaking restent prévisibles. Utilisez la forme de déclaration exigée par le dépôt pour les propriétés publiques des composants et exportez depuis le module du composant une interface de propriétés dont le nom est cohérent. Préservez les alias de chemins et les conventions d’exportation publique. Dans l’espace de travail, utilisez des importations de paquets ciblées et limitées à un seul niveau lorsque des importations générales depuis des fichiers d’agrégation intégreraient un paquet entier dans un bundle. Considérez la forme des importations comme un contrat de performance et de conditionnement, et non comme une préférence de style. ## Écrire des erreurs qui disent ce qui s’est passé et comment le corriger Toute erreur lancée depuis un paquet public doit indiquer ce qui s’est passé, pourquoi cela importe et ce que l’appelant peut faire pour y remédier. Utilisez le préfixe obligatoire de la bibliothèque, une construction de message lisible et un lien vers la documentation lorsqu’il existe des instructions maintenues. Appliquez le marqueur de minification des erreurs du dépôt aux constructeurs d’erreurs pris en charge, afin que les bundles de production puissent remplacer les messages longs par des codes stables tout en conservant des messages compréhensibles pendant le développement. Après l’ajout ou la modification d’une erreur publique, générez à nouveau le catalogue des codes d’erreur. Si la sémantique et le nombre d’arguments restent inchangés, mettez à jour l’entrée existante du catalogue au lieu de créer un nouveau code pour le même contrat d’erreur. ## Tester les composants comme un utilisateur qui clique et tape Utilisez le moteur de rendu et les utilitaires d’assertion partagés du dépôt afin que les tests de composants correspondent à l’environnement pris en charge. Préférez les requêtes accessibles et les interactions utilisateur complètes au déclenchement d’événements de bas niveau ou à la modification directe de propriétés. Testez le comportement observable, les transitions d’état, les avertissements et les erreurs avec les comparateurs configurés. Gardez les tests unitaires ciblés et utilisez des filtres de nom pendant l’itération sans confondre la réussite d’une exécution filtrée avec une couverture complète. Lorsqu’un test nécessite une mise en page, des API de navigateur ou un comportement de rendu indisponible dans un DOM simulé, limitez-le à l’environnement de navigateur réel pris en charge et documentez la raison dans la condition du test. ## Couper les captures d’écran sans couper les vérifications d’accessibilité Exécutez l’analyse d’accessibilité dans la boucle de régression sur navigateur établie lorsque le dépôt partage cette session. Considérez les captures d’écran et les assertions d’accessibilité comme des contrôles indépendants : une démonstration peut désactiver l’un sans désactiver implicitement l’autre. Rendez explicite la couverture des règles d’accessibilité. Consignez les résultats réussis, échoués et incomplets par démonstration et par règle, incluez les balises applicables de la norme d’accessibilité et conservez les assertions obligatoires, sauf si une exception étroitement délimitée et dûment justifiée est configurée. Ne lancez pas un flux de travail de navigateur distinct lorsque l’infrastructure de régression intégrée gère déjà la navigation, le rendu, les captures d’écran et l’analyse d’accessibilité. ## Ordonner les règles d’exception pour qu’ignorer une démo n’en ignore pas d’autres Faites correspondre la configuration de régression à des identifiants de démonstration stables. Lorsque les règles appliquent une priorité où la dernière correspondance l’emporte sans héritage, placez les remplacements ciblés après les règles générales et redéclarez chaque champ que le remplacement doit conserver. Utilisez des motifs ciblés pour les démonstrations individuelles et des motifs plus généraux uniquement pour un groupe complet de composants. Une règle qui désactive une seule démonstration ne doit pas désactiver accidentellement les démonstrations sœurs ni hériter de champs d’exception obsolètes. Générez à nouveau les résultats structurés d’accessibilité et visuels après toute modification des règles. L’intégration continue doit rejeter les rapports générés obsolètes au lieu d’accepter silencieusement une configuration qui n’a jamais été exécutée. ## Tester seulement ce qui est concerné pendant le travail, puis tout tester avant d’envoyer Limitez les exécutions locales de régression avec le filtre de nom du lanceur de tests, afin que les tests qui ne correspondent pas au filtre ne déclenchent pas de navigation dans le navigateur et ne réécrivent pas de résultats sans rapport. Vérifiez que le filtre correspond à la route ou à l’identifiant de démonstration intégré au nom du test. Gardez à l’esprit qu’une exécution filtrée actualise uniquement les rapports des composants correspondants. Avant de pousser les modifications, exécutez la commande de régression sans filtre afin que chaque rapport, capture d’écran et résultat d’accessibilité soit à jour. Conservez le serveur de régression et le lanceur comme processus distincts lorsque le flux de travail du dépôt l’exige, et préservez la syntaxe documentée du gestionnaire de paquets pour la transmission des arguments. ## Régénérer la documentation de l’API et les démos après la modification d’un composant Après avoir modifié les propriétés d’un composant ou les déclarations de types, exécutez les générateurs d’extraction des propriétés et de documentation des API. Examinez la différence obtenue dans l’API publique avec la modification du code source. Créez la démonstration typée désignée comme source faisant autorité et générez les variantes dans d’autres langages au moyen du formateur ou du convertisseur pris en charge. Ne modifiez pas manuellement une variante de démonstration générée comme seule correction. Lorsque des démonstrations ou Markdown changent, exécutez les contrôles correspondants de génération des démonstrations, de compilation de la documentation, de style rédactionnel et de grammaire. Conservez les instructions d’intégration spécialisées dans des modules d’instructions locaux autonomes et chargez le module pertinent pour les travaux concernant les styles, les thèmes, le rendu ou l’intégration avec des frameworks. ## Faire les vérifications que demande la modification et signaler celles qui manquent Avant la revue, formatez les fichiers modifiés, exécutez le lint et la vérification des types, lancez des tests unitaires ciblés, puis étendez les contrôles aux navigateurs réels, aux tests de bout en bout, aux contrôles visuels, à l’accessibilité, à la documentation des API ou au texte selon le comportement concerné. Vérifiez les codes d’erreur générés, les références d’API, les variantes de démonstration, les captures d’écran et les rapports d’accessibilité lorsque leurs sources ont changé. Signalez tout contrôle bloqué ou non exécuté au lieu de présenter une vérification partielle comme complète. Gardez la revue centrée sur le composant et utilisez le format de titre de modification exigé par le dépôt : une portée stable de composant ou de documentation suivie d’une description à l’impératif.