Qué hace .editorconfig
Tres ingenieros sobre el mismo repo, tres editores distintos: VS Code en Windows que añade CRLF, vim en Linux con tabs de 4 espacios, JetBrains en macOS con un ancho de tab personalizado. Tres semanas después el diff está lleno de cambios invisibles de espacios en blanco, cada PR trae ruido, el blame se vuelve inútil.
Un archivo `.editorconfig` es la solución simple. Es una configuración única en la raíz del repo que cada editor moderno lee automáticamente (VS Code, JetBrains, vim, emacs, Sublime, Atom): qué estilo de sangrado, cuántos espacios, qué fin de línea, qué charset, si recortar espacios al final, si añadir un salto de línea final. Sin plugin que instalar en los editores populares, sin configuración por persona.
Este generador escribe ese archivo por ti. Elige un preset para tu stack (JavaScript/TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux), retoca los valores por defecto, añade overrides por patrón para archivos que necesitan reglas distintas (`Makefile` siempre quiere tabs, `*.md` debe mantener espacios al final porque así se codifican los saltos), copia o descarga como `.editorconfig`, commitea. Listo en dos minutos.
Cómo se usa
- Elige un preset arriba: JavaScript/TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux. Cada uno pone valores sensatos por defecto que puedes cambiar.
- Deja root = true activado. Le dice a los editores "deja de buscar hacia arriba en el árbol de directorios". Sin esto, un `.editorconfig` superior en la jerarquía (p. ej. en tu home) puede pisar el tuyo.
- Edita la **sección por defecto [*]: qué charset, end_of_line, insert_final_newline, trim_trailing_whitespace, indent_style, indent_size, max_line_length**.
- Añade overrides por patrón para archivos con reglas distintas. `Makefile` debe usar tabs reales (Make rechaza tabs convertidos en espacios). **`*.md` debe mantener los espacios al final (en markdown un salto de línea se codifica con dos espacios al final). `*.go`** suele usar tabs de ancho 4.
- Para repos solo Windows con scripts de shell puedes mezclar finales: **`*.{ps1,bat,cmd}` = crlf, `*.sh` = lf**. Mezclar finales en `.sh` rompe la ejecución en Linux.
- Para vaciar un campo pulsa "keep" en la barra segmentada. La clave se omite de la salida en esa sección, así que gana el valor de una sección padre (o el predeterminado del editor).
- Pulsa Copiar o Descargar para guardar como `.editorconfig` y commitea en la raíz del repo. Cada IDE lo recoge al abrir; los editores populares no necesitan instalación.
Cuándo te resulta útil
Seis situaciones concretas en las que añadir un .editorconfig ahorra tiempo real al equipo:
- Primer commit en un repo nuevo. Eliges el preset adecuado para tu stack, dejas `.editorconfig` en la raíz y commiteas. A partir de ahora todo editor que abra este repo usa la misma sangría y los mismos finales de línea sin que nadie tenga que configurar nada.
- Equipo multi-SO (Windows + macOS + Linux). La fuente número uno de PRs con "diff espurio" son los finales de línea. Poner `end_of_line = lf` una vez mata toda la categoría, independientemente de la magia de `autocrlf` de git.
- Aterrizar a un dev nuevo. Clona el repo, abre su editor favorito y la sangría funciona sin más. Sin sorpresas tipo "¿por qué mi IDE me sangra con 4 espacios aquí?".
- Proyecto open-source que acepta PRs externas. Los contribuyentes usan editores cualesquiera. Sin `.editorconfig`, la mitad de las PRs necesitan un commit de "fix whitespace". Con él, el diff de la PR es solo el cambio real.
- Repo multilenguaje. Python quiere 4 espacios, JS quiere 2, Go tabs de 4, YAML 2 espacios, los Makefile tabs literales. Un `.editorconfig` con unos bloques por patrón cubre todo en veinte líneas.
- Pre-commit hook de whitespace. Combinado con un pre-commit hook (el framework `pre-commit` tiene integración con `editorconfig-checker`), las reglas dejan de ser sugerencias y se vuelven exigibles.