Générateur de .editorconfig

Qu'est-ce qu'un fichier .editorconfig ?

Un fichier .editorconfig demande à tous les éditeurs d'un projet de s'accorder sur les sujets ennuyeux : tabulations ou espaces, combien, quelle fin de ligne, faut-il supprimer les espaces en fin de ligne. Il vit dans votre dépôt, la plupart des éditeurs le lisent sans extension, et il tranche des débats qui reviendraient sinon à chaque relecture de code.

Le format est volontairement minuscule. Un en-tête de section est un motif entre crochets, les lignes en dessous sont des affectations de propriétés, et le fichier situé à la racine du projet se signale par root = true pour que la recherche s'arrête là. C'est à peu près tout, et c'est pourquoi on en écrit un en une minute avant de passer une heure à se demander pourquoi tel fichier ne reçoit pas les réglages attendus.

Cet outil couvre les deux moitiés. Vous modifiez le fichier en haut et, en dessous, vous lui donnez un chemin : il vous dit exactement quelle section fournit chaque propriété — car c'est la question à laquelle un .editorconfig ne répond pas à la simple lecture.

Comment l'utiliser

1. Partez du fichier affiché. C'est un point de départ raisonnable, avec les propriétés que veulent presque tous les projets. Modifiez-le directement : ajoutez des sections, changez des valeurs, supprimez ce dont vous n'avez pas besoin.
2. Saisissez un chemin à tester. Relatif à l'endroit où se trouve le .editorconfig, avec des barres obliques. Essayez l'un de vos fichiers récalcitrants : celui dont vous soupçonnez qu'il ne reçoit pas les réglages voulus.
3. Regardez quelle section l'a emporté. Chaque propriété appliquée est listée avec le motif qui l'a fournie, et chaque section correspondante indique combien de ses propriétés ont survécu. Tout écart à la spécification est signalé en dessous.

La dernière l'emporte, et la précision ne compte pour rien

C'est la règle qui coûte un après-midi. Quand deux sections correspondent à un fichier, celle écrite plus bas fournit la valeur. La précision apparente du motif n'entre absolument pas en jeu : pas de score, pas de correspondance la plus spécifique, rien de la mécanique que CSS ou les tables de routage vous ont appris à attendre.

Une section large placée en bas du fichier écrase donc silencieusement les sections par langage soigneusement écrites au-dessus. Si vous ajoutez une règle de rangement générale à la fin d'un long .editorconfig, vous venez de changer le comportement de tout ce qui précède, pour chaque propriété que vous y définissez. Le vérificateur de cette page montre précisément cela : chaque section correspondante indique combien de ses propriétés ont réellement atteint la réponse finale.

Entre fichiers, le sens s'inverse, et cela mérite d'être rangé à part dans la tête. L'éditeur part du fichier en cours d'édition et remonte l'arborescence, lisant les fichiers les plus proches en dernier pour qu'ils l'emportent, et s'arrête dès qu'il en rencontre un portant root = true. Oubliez cette ligne et un .editorconfig d'un répertoire parent — ou de votre dossier personnel — continuera de s'appliquer à votre projet.

La syntaxe des motifs n'est pas celle de gitignore

Les motifs ressemblent à ceux de gitignore sans en être, et c'est la deuxième source fiable de surprise. À côté de l'astérisque et du point d'interrogation habituels, qui s'arrêtent au séparateur de répertoires là où le double astérisque le franchit, EditorConfig dispose de l'alternance par accolades et de quelque chose que gitignore n'a jamais eu : un intervalle d'entiers. Le motif file{1..3}.txt correspond à file2.txt mais pas à file4.txt, et chacune des bornes peut être négative.

Cet intervalle a un piège, et il échoue en silence. Le premier nombre doit être inférieur au second, si bien que {3..1} n'est pas un intervalle et correspond littéralement à ces cinq caractères. Rien ne vous prévient. Le même piège guette une accolade à élément unique : {s1} correspond à un fichier réellement nommé {s1}, pas à un fichier nommé s1, et la spécification le dit dans une parenthèse qu'on lit sans la voir.

Les crochets sont plus stricts qu'ils n'en ont l'air, et ce cas a également pris en défaut l'implémentation de référence. La spécification indique que chaque caractère placé entre crochets est littéral : [a-c] est donc l'ensemble de trois caractères a, trait d'union et c, et ne correspond pas à b. À peu près tous les autres langages de motifs lisent a-c comme un intervalle, et c'est exactement pour cela qu'il vaut la peine de savoir qu'ici non.

Enfin, la présence d'une barre oblique décide de la portée d'un motif. Celui qui en contient se mesure depuis le répertoire du .editorconfig ; celui qui n'en contient pas peut correspondre à n'importe quelle profondeur en dessous. C'est pourquoi [*.py] couvre toute votre arborescence alors que [src/*.py] n'en couvre qu'un seul répertoire.

Limites assumées

Cette page applique la spécification, et les éditeurs ne l'appliquent pas uniformément. Les sept propriétés proposées ici sont celles que la spécification définit et pour lesquelles la prise en charge est raisonnablement fiable, mais un éditeur reste libre d'en ignorer n'importe laquelle, et plusieurs des plus répandus réclament une extension avant même de lire le fichier. Si un réglage reste sans effet, vérifiez que votre éditeur gère cette propriété avant de conclure que le fichier est fautif.

Le vérificateur travaille par ailleurs sur le fichier qu'on lui donne. Un vrai projet peut comporter plusieurs .editorconfig à des profondeurs différentes, et la réponse pour un chemin dépend de tous, plus de l'endroit où la recherche s'arrête. Ce qui est modélisé ici, c'est un fichier et les règles qui le régissent — là où se niche presque toujours la partie déroutante.

Une chose découverte en construisant ceci mérite d'être transmise : l'implémentation de référence et cet outil divergent sur les expressions entre crochets contenant des caractères de motif, et la spécification donne raison à cet outil. Son propre exemple résolu est un motif que la référence traite mal. C'est un recoin que personne n'écrit exprès, mais il rappelle que les cas limites d'un format de configuration sont tranchés par ce que votre éditeur embarque.

Pourquoi est-ce gratuit ?

Tout tourne dans votre navigateur. Confronter un chemin à un motif ne coûte rien sur votre propre machine : il n'y a donc aucun serveur à financer et aucune raison de vous réclamer un compte.

Rien de ce que vous saisissez n'est envoyé, conservé ni journalisé. L'arborescence et les noms de fichiers en disent long sur une base de code privée, et la façon fiable de garder cela privé est de ne l'envoyer nulle part.