Probador de EditorConfig

Cómo usar

1. Pega el .editorconfig en el primer cuadro. Si tienes varios archivos, introduce cada uno con una línea marcador como «# path: vendor/.editorconfig» y pon primero el de la raíz del proyecto.
2. Escribe las rutas a probar en el segundo cuadro, una por línea, relativas a la raíz del proyecto: el directorio que contiene el .editorconfig superior.
3. Lee la tabla de cada ruta: la propiedad, el valor resuelto y el archivo, la línea y el glob de la sección que lo definió. Una fila marcada como derivada no está escrita en ningún archivo; la nota indica qué regla la produjo.
4. Revisa la cadena de búsqueda sobre cada tabla: los .editorconfig consultados, del más cercano al más lejano, y si root = true detuvo el recorrido o este continuaría por encima de tu proyecto.
5. Repasa el panel de hallazgos. Cada entrada apunta a un archivo y una línea donde la configuración hace algo distinto de lo que aparenta: una sección muerta, un ajuste que nunca gana, un espacio dentro de unas llaves.

Preguntas frecuentes

¿Por qué mi archivo usa cuatro espacios si [*] dice dos?

Porque ganó algo posterior o más cercano, y en EditorConfig no hay una jerarquía de especificidad a la que apelar. Dentro de un archivo gana la última sección que coincide, así que un bloque [*.py] veinte líneas más abajo sustituye sin avisar a tu bloque [*], igual que un segundo bloque [*] más abajo: por eso importa un nombre de sección repetido. Entre archivos gana, propiedad a propiedad, el .editorconfig más cercano, de modo que un archivo de dos líneas en el directorio que estás editando vence al archivo cuidado de la raíz. El orden y la distancia son toda la historia, y eso es justo lo que informa la columna «Definida en»: el archivo, la línea y el glob de la sección que produjo el valor, con los ajustes a los que venció listados debajo.

¿Qué diferencia hay entre [*.js], [lib/*.js] y [**/*.js]?

La presencia de una barra, y nada más. Un glob sin barra se compara solo con el nombre del archivo a cualquier profundidad, así que [*.js] cubre src/a.js y vendor/dist/b.js por igual. En cuanto el glob contiene una barra en cualquier posición salvo el final, queda anclado al directorio del .editorconfig que lo contiene: [lib/*.js] coincide con lib/a.js y no con lib/sub/a.js, ni con src/lib/a.js. [**/*.js] es la forma anclada que cruza directorios, porque ** atraviesa las barras donde un solo * se detiene, y el /**/ intermedio también representa la ausencia de directorio, de modo que coincide tanto con a.js como con lib/sub/a.js. Una trampa final: una barra al final, como en [lib/], no coincide con nada, porque la ruta de un archivo nunca termina en barra. El subárbol se escribe [lib/**].

¿De dónde salen indent_size = tab y tab_width si nunca los escribí?

De las reglas de reserva que el núcleo aplica después de fusionarlo todo. Si indent_style es tab y no se definió indent_size, indent_size pasa a ser la palabra tab. Si indent_size es un número y no hay tab_width, tab_width lo copia, por eso un archivo que solo menciona indent_size informa también de un tab_width. Y en sentido contrario, si indent_size vale tab y existe un tab_width, indent_size toma ese número. Como ocurre sobre el resultado ya fusionado, las dos mitades pueden venir de archivos distintos: un tab_width de la raíz puede alimentar un indent_size escrito tres directorios más abajo. unset recorre la misma maquinaria, así que indent_size = unset deja también tab_width en unset.

¿Qué detiene realmente root = true?

La búsqueda hacia arriba de más archivos .editorconfig. Sin él, el recorrido no se detiene en tu proyecto: sigue por todos los directorios superiores, incluidos tu carpeta personal y la raíz del sistema de archivos, y lo que encuentre allí rellena las propiedades que tu archivo no definió. Dos detalles deciden si funciona. Debe estar en el preámbulo, por encima de la primera cabecera de sección: escrito dentro de un bloque [*] es solo una propiedad corriente llamada root y no detiene nada. Y se lee aunque ninguna sección de ese archivo coincida, así que una configuración con todas las secciones equivocadas termina igualmente la búsqueda.

¿Por qué [*.{js, ts}] no se aplica a mis archivos .ts?

Porque el espacio forma parte del patrón. La alternancia entre llaves compara literalmente las cadenas separadas por comas, sin recortar espacios en ningún punto de una cabecera de sección, así que {js, ts} ofrece «js» y « ts», y solo coincide con la segunda un archivo cuyo nombre contenga de verdad un espacio antes de ts. Conviene conocer dos trampas vecinas: {js} sin coma no es alternancia y coincide con los caracteres literales {js}, de forma que [*.{js}] se aplica a un archivo llamado app.{js} y a ningún otro; y un rango numérico como {1..10} rechaza el cero a la izquierda, así que 1.txt y 10.txt coinciden pero 01.txt no.

¿Una barra invertida escapa un asterisco?

No en la implementación de referencia, diga lo que diga la documentación. El núcleo traduce el glob a una expresión regular en una sola pasada y el escape solo se respeta para la coma, la llave de cierre, # y ;, es decir, los caracteres que si no terminarían el patrón o partirían una alternancia. Una barra invertida delante de un asterisco o de una interrogación se descarta y el comodín sigue coincidiendo con cualquier cosa, de modo que [a\*b.txt] también coincide con aXb.txt. Peor aún, \[ y \{ dejan la expresión generada sin equilibrar: compilar el glob lanza un error y el plugin del editor suele reaccionar ignorando el .editorconfig entero sin decirlo. Esta herramienta reproduce ese comportamiento en lugar de adivinar y marca la sección como un glob inservible. El consejo práctico es mantener llaves, corchetes y asteriscos fuera de las cabeceras de sección.

Herramientas relacionadas