Ajouter des extensions de fichier ou de nouveaux langages à un dépôt de détection des langages

## Repérer quels fichiers et outils gèrent chaque partie de la détection Avant toute modification, déterminez quels fichiers et outils contrôlent chaque partie de la détection des langages : - le registre des langages pour les noms, extensions, noms de fichiers et propriétés des langages ; - les règles heuristiques et leur mise en œuvre pour les fichiers ambigus ; - le classificateur statistique et son corpus d’échantillons réels ; - le registre des grammaires utilisé pour la coloration syntaxique ; - les sources de grammaires intégrées et les données de licence mises en cache ; - les scripts de maintenance, les tests et les points d’entrée de l’intégration continue. Considérez ces éléments comme des contrats coordonnés. Une modification de métadonnées peut exiger des échantillons, des heuristiques, des identifiants générés, des données de grammaire, des tests et des preuves, plutôt qu’une modification isolée. ## Préparer le projet dans le conteneur de développement et utiliser ses scripts Lorsqu’il est disponible, privilégiez le conteneur de développement ou l’environnement hébergé maintenu par le dépôt. Il doit fournir l’environnement d’exécution du langage déclaré, les outils de gestion des paquets, l’environnement d’exécution des conteneurs, les bibliothèques natives et toutes les dépendances du projet. Pour travailler localement : 1. Exécutez la commande de préparation de référence. 2. Appelez la bibliothèque ou l’outil en ligne de commande au moyen de l’exécuteur de dépendances du dépôt. 3. Utilisez les scripts de maintenance documentés au lieu de reproduire leurs effets à la main. 4. Vérifiez la présence des dépendances natives nécessaires à la détection des encodages, à l’accès au dépôt ou au travail sur les grammaires. Ne considérez pas la réussite d’un appel local improvisé comme la preuve que l’environnement pris en charge passera les vérifications. ## Ajouter une extension par ordre alphabétique, avec de vrais échantillons Pour ajouter une extension de fichier à un langage existant : 1. Mettez à jour l’entrée de référence du langage. 2. Conservez les listes d’extensions dans l’ordre alphabétique requis, sensible à la casse, avec les majuscules avant les minuscules et l’extension principale en premier. 3. Ajoutez, sous le langage concerné, des fichiers d’exemple représentatifs d’usages réels. 4. Si un autre langage partage l’extension, fournissez au moins deux échantillons et ajoutez une heuristique de désambiguïsation. 5. Ajoutez ou mettez à jour les tests portant sur les métadonnées et le comportement de l’heuristique. N’utilisez pas comme preuves pour le classificateur des exemples courants de tutoriels, tels que de simples programmes de salutation. Les échantillons doivent refléter du code réel que le détecteur doit reconnaître. ## Ajouter un nouveau langage avec sa grammaire et un identifiant généré par script Un nouveau langage exige plus qu’une étiquette dans le registre : 1. Ajoutez l’entrée du langage, mais laissez son identifiant généré sans valeur. 2. Enregistrez une grammaire de coloration syntaxique approuvée et compatible au moyen de l’outil de grammaire de référence. 3. Ajoutez des fichiers d’exemple représentatifs provenant de sources originales vérifiables. 4. Exécutez le script de génération des identifiants au lieu d’attribuer manuellement un identifiant. 5. Si une extension est partagée, fournissez au moins deux échantillons et ajoutez des règles de désambiguïsation testées. 6. Vérifiez ensemble les métadonnées, l’enregistrement de la grammaire, la classification et les modifications générées. Préservez les instructions d’en-tête du registre, les exigences relatives aux champs et l’ordre sensible à la casse. ## Écrire des règles regex testées pour distinguer les langages qui partagent une extension Les heuristiques doivent résoudre de véritables ambiguïtés sans produire de nombreux faux positifs. - Recherchez le plus petit indice distinctif séparant les langages concurrents. - Maintenez chaque motif linéaire par rapport à la taille de l’entrée. - Évitez les constructions vulnérables aux attaques par déni de service au moyen d’expressions régulières. - N’utilisez que la syntaxe prise en charge par le moteur d’expressions régulières imposé par le dépôt. - Testez les cas positifs, les cas du langage concurrent et les cas proches de la limite. - Exécutez une validation croisée du classificateur lorsqu’une modification d’heuristique ou d’échantillon peut déplacer le comportement de détection. Chaque heuristique doit disposer de tests. Une règle qui reconnaît la cible mais capture également des fichiers sans rapport n’est pas acceptable. ## Régénérer les fichiers avec les commandes de maintenance au lieu de les modifier à la main Ne modifiez pas à la main les registres générés, les déclarations de modules, le contenu des grammaires intégrées ni les fichiers de licence de grammaire mis en cache. Utilisez la commande de maintenance responsable pour ajouter ou remplacer une grammaire, puis examinez toutes les modifications qu’elle génère. Avant d’accepter une grammaire : - confirmez sa compatibilité avec le format de coloration syntaxique utilisé par le projet ; - vérifiez que sa licence figure dans la liste approuvée ; - conservez l’URL de référence de la source et l’enregistrement de la licence ; - exécutez la validation propre à la grammaire dans l’environnement de conteneur pris en charge. Si le résultat généré est incorrect, corrigez l’entrée source ou le processus de génération au lieu de modifier directement le résultat. ## Lancer la validation croisée du classificateur et toute la suite de tests Exécutez d’abord les vérifications pertinentes les plus ciblées, puis toute la validation obligatoire du dépôt : 1. Validez les métadonnées modifiées et leur ordre. 2. Exécutez les tests portant sur les nouveaux échantillons et les nouvelles heuristiques. 3. Exécutez une validation croisée du classificateur lorsque les limites de détection peuvent changer. 4. Exécutez l’ensemble complet des tests au moyen de l’exécuteur de dépendances de référence. 5. Confirmez que l’intégration continue réussit les mêmes étapes obligatoires. Examinez les échecs afin de repérer les faux positifs, les divergences de fichiers générés, les dépendances natives manquantes, les données de grammaire non valides et les modifications involontaires de langages sans rapport. ## Montrer les preuves d'usage et les licences des échantillons avant l'envoi Avant d’ouvrir une demande de contribution : - utilisez le modèle fourni et ne retirez que les sections sans rapport ; - fournissez un lien vers des preuves de recherche publique pour chaque extension ajoutée, en excluant les bifurcations ; - présentez au moins 2000 fichiers indexés pour les extensions courantes, ou 200 fichiers pour les noms qui n’apparaissent normalement qu’une fois par dépôt ; - vérifiez une répartition raisonnable entre différentes combinaisons d’utilisateurs et de dépôts, en tenant compte des utilisateurs dont la part est anormalement élevée ; - reliez chaque échantillon à sa source originale, et non à la bifurcation utilisée pour la contribution ; - indiquez séparément la licence de chaque échantillon de code ; - réussissez tous les tests obligatoires et toutes les vérifications d’intégration continue ; - gardez la modification ciblée et ne l’associez pas à une restructuration sans rapport. Si une exigence n’est pas satisfaite, n’ouvrez pas la demande. Expliquez quelle preuve, quelle licence, quel test ou quelle condition de périmètre manque et ce qui doit être terminé en premier.