Validador de archivos de configuración

Funciones

• package.json: sintaxis JSON, reglas del nombre del paquete (npm rechaza mayúsculas y espacios), forma de la versión, rangos de dependencias y licencia / description / repository ausentes
• `.env`: claves duplicadas (listando cada línea en la que aparecen — tres veces son tres líneas), puntos y guiones en el nombre, valores vacíos, comillas sobrantes alrededor del valor
• ⚠️ Mayúsculas en las claves de `.env`: un nombre que no está en mayúsculas es solo una sugerencia; dos claves que difieren solo en mayúsculas (DATABASE_URL frente a database_url) suben a aviso, con la diferencia entre plataformas explicada — en Windows se sobrescriben entre sí, mientras que Linux / macOS las trata como dos variables independientes
• robots.txt: `Disallow: /` bloqueando todo el sitio, un `Disallow:` vacío que significa lo contrario, un Sitemap que no es absoluto, un User-agent que falta
• ⚠️ robots.txt puede probar una ruta: da una ruta y uno o más rastreadores (uno por línea, las comas valen) y dirá permitido o bloqueado para cada uno, nombrando la regla que ganó y por qué (gana el grupo más específico, luego la coincidencia más larga, y Allow en caso de empate, con soporte de `*` y `$`)
• sitemap.xml: la declaración de espacio de nombres, valores `<loc>` relativos, duplicados y los límites de 50.000 URL y 50 MB
• ⚠️ sitemap entiende los dos elementos raíz: `<urlset>` (lista páginas) y `<sitemapindex>` (lista otros sitemaps). Mezclar la raíz con el hijo equivocado — un `<url>` dentro de un índice, o al revés — hace que los rastreadores no lean nada, por eso se informa aparte
• ⚠️ `.env` puede encontrar claves sin referenciar: pega el código que lee el archivo y listará las claves que no aparecen nunca. Es una búsqueda de texto (con límites de palabra, así que `DATABASE_PORT` no hace que `PORT` cuente como usada): `process.env.X`, `process.env['X']` y la desestructuración `const { X } = process.env` se detectan, pero las lecturas dinámicas (`process.env[name]`, una clave montada) no — así que aparecer no prueba que esté muerta, ni callar prueba que se use
• Cabeceras HTTP: X-XSS-Protection / Expect-CT / HPKP obsoletas, y CSP, HSTS, nosniff y compañía ausentes
• ⚠️ Los hallazgos se dividen en errores (roto) / avisos (funciona, pero seguramente no es lo que querías) / sugerencias (se puede mejorar) y se ordenan así
• ⚠️ `Access-Control-Allow-Origin: *` con `Allow-Credentials: true` lo rechazan los navegadores sin más, y se informa como error
• ⚠️ Cada hallazgo da el motivo: no «no cumple», sino qué se rompe si lo dejas
• Detecta qué tipo de archivo pegaste, y te deja cambiarlo
• Se ejecuta por completo en tu navegador; no se sube nada ni se guarda

Cómo se usa

1. Pega la configuración; el tipo se detecta automáticamente
2. Cambia el tipo en las opciones si la detección se equivoca
3. Lee los hallazgos errores → avisos → sugerencias, cada uno con su motivo

Preguntas frecuentes

¿Por qué tres niveles y no un «pasa / no pasa»?

Porque un validador de pasa/no pasa te entrega una pared de fallos sin orden, y la gente deja de leer y lo ignora todo — que es exactamente como un validador deja de servir. Aquí los «errores» son lo que hace que rechacen el archivo (JSON mal formado, un `<loc>` relativo, esa pareja de CORS, la misma clave escrita dos veces), los «avisos» funcionan pero seguramente no son lo que querías (`Disallow: /` bloqueando todo, dos claves que solo difieren en mayúsculas), y las «sugerencias» son mejoras (falta la licencia, un nombre de clave que no está en mayúsculas). Ordenados así, lo primero que hay que arreglar salta a la vista.

¿Por qué un `Disallow:` vacío es un hallazgo?

Porque un valor vacío y una barra difieren en un carácter y significan lo contrario: `Disallow:` significa permitir todo, `Disallow: /` bloquea todo el sitio. Es lo más fácil de poner al revés en un robots.txt, y ponerlo al revés es silencioso por los dos lados: por uno los buscadores dejan de venir sin avisar, por el otro una regla de pruebas que nadie quitó te cuesta todo el tráfico orgánico tras el lanzamiento.

¿Por qué una clave de entorno duplicada es un error y no una pista?

Porque casi todos los cargadores (dotenv, Docker, systemd) toman el último valor, mientras que escribir una clave dos veces normalmente significa que querías que ganara ese valor — así que la copia que editaste es la que se ignora, y eso es invisible mientras depuras: el archivo muestra claramente el valor que quieres y el programa lee otro. Está entre las causas principales de incidentes reales, así que se informa como error, listando cada línea en la que aparece la clave (tres veces son tres líneas): saber «está duplicada» no basta, hace falta saber qué copias borrar.

DATABASE_URL y database_url son dos claves distintas, ¿por qué se avisa?

Porque en Windows no son dos claves. Windows trata los nombres de variable de entorno sin distinguir mayúsculas, así que dos claves que solo difieren en eso se sobrescriben entre sí (cuál gana depende del orden de carga), mientras que en Linux / macOS son dos variables independientes. El mismo `.env` se comporta distinto en cada sistema — bien en tu Mac, mal en la CI de Windows — lo que lo convierte en uno de los fallos más difíciles de rastrear. Por eso tiene su propio aviso, nombrando las dos claves y sus números de línea. Va aparte de «el nombre no está en mayúsculas», que es solo una sugerencia porque un nombre en minúsculas suelto funciona en las dos plataformas.

¿La comprobación de «claves sin referenciar» puede fallar por exceso o por defecto?

Las dos cosas, porque es una búsqueda de texto, no un análisis. Detecta `process.env.X`, `process.env['X']` y la desestructuración `const { X } = process.env` (el nombre de la clave aparece como texto), pero no una lectura dinámica como `process.env[name]` o una clave montada — esa clave se listará como no referenciada, que es un falso positivo. Al revés, que el nombre aparezca en un comentario o en una cadena cualquiera cuenta como uso, y eso es un falso negativo. Así que «no aparece» no significa que se pueda borrar, ni «aparece» que esté muerta: tómalo como una pista y busca en todo el repositorio antes de borrar.

¿Por qué la comprobación de rangos de dependencias es tan permisiva?

Porque el valor de `dependencies` puede ser `workspace:*`, `file:../x`, una URL de git, un alias `npm:`, o un conjunto de comparadores separados por espacios como `>=1.0.0 <2.0.0`. Juzgar esa gramática entera obliga a traer una librería de semver, y el objetivo aquí no es validar la semántica — es cazar los errores evidentes (una cadena vacía, `^abc`, `1.0.0.0`). Cada hallazgo le pide a quien lee que edite un archivo de configuración, así que un falso positivo le cuesta a la herramienta su credibilidad.

¿Lee también mis secretos?

No. Todo se ejecuta en el navegador, no se sube nada ni se guarda. Además solo mira la sintaxis y la estructura: lo que venga detrás de `API_KEY=` no influye en si el nombre de la clave es válido o en si el archivo repite una clave, así que ningún valor se inspecciona.