Los errores de JavaScript caen en tres categorías bien diferenciadas - sintaxis, tiempo de ejecución y lógica - y la herramienta adecuada para encontrar cada una es distinta. Un comprobador de sintaxis detecta problemas estructurales antes de que el motor ejecute tu código; un decodificador de errores en tiempo de ejecución explica mensajes crípticos cuando ya han aparecido; un analizador estático encuentra bugs potenciales que ninguna de las dos aproximaciones toca. Esta guía asocia cada categoría de error de JavaScript con la mejor herramienta para detectarla, con flujos de trabajo para el navegador, Node.js y pipelines de CI/CD.
Tipos de errores de JavaScript
Cada error de JavaScript que te encuentres pertenece a una de tres categorías, y confundirlas lleva a usar la herramienta equivocada. Entender primero las categorías ahorra mucho tiempo de depuración porque te dice exactamente dónde mirar y qué tipo de comprobador ayudará.
Errores de sintaxis
Los errores de sintaxis los detecta el parser de JavaScript antes de que se ejecute una sola línea de código. Significan que el motor no puede interpretar la estructura del archivo - una llave de cierre ausente, un token inesperado, una palabra reservada usada como nombre de variable o un literal de cadena sin cerrar. El error se lanza en tiempo de análisis con un número de línea y una breve descripción. Un comprobador o validador de sintaxis los detecta sin ejecutar el código.
Errores en tiempo de ejecución
Los errores en tiempo de ejecución se lanzan durante la ejecución, cuando código sintácticamente válido intenta realizar una operación ilegal. Los más comunes: acceder a una propiedad sobre `null` o `undefined` (`TypeError`), llamar a algo que no es una función (`TypeError`), referenciar una variable que no existe (`ReferenceError`) o dividir por un valor no numérico (`NaN` - que falla silenciosamente). Estos errores necesitan un entorno en ejecución, un decodificador de stack traces o un análisis estático cuidadoso para detectarse.
Errores de lógica
Los errores de lógica producen una salida incorrecta sin lanzar ningún error - un bucle con desajuste de uno, un condicional incorrecto, una mutación donde se pretendía una copia. Ningún validador o comprobador de sintaxis los detecta; requieren tests unitarios, revisión de código o una sesión de depurador. El conjunto de reglas de ESLint solapa con algunos patrones de error lógico (p. ej. marcar `==` en lugar de `===`), pero la mayoría de los bugs de lógica solo se encuentran ejecutando el código con datos reales.
- SyntaxError: Detectado en tiempo de análisis - corchete ausente, token incorrecto, cadena sin cerrar.
- TypeError: Acceder a `.propiedad` sobre null/undefined, llamar a algo que no es función.
- ReferenceError: Usar una variable que nunca fue declarada en el ámbito actual.
- RangeError: Pasar un valor fuera del rango permitido - p. ej. `new Array(-1)`.
- URIError: URI malformada pasada a `decodeURIComponent` o `encodeURIComponent`.
- Bug de lógica: Salida incorrecta, sin error lanzado - requiere tests o depurador.
Note
Comprobadores de sintaxis de JavaScript
Un comprobador de sintaxis de JavaScript (también llamado validador de sintaxis) analiza tu código sin ejecutarlo y notifica cada punto donde la estructura viola la gramática de JavaScript. Es la primera comprobación más rápida y segura - detecta los errores que impedirían que tu código se ejecutase siquiera, y lo hace en milisegundos sin efectos secundarios.
Cuándo usar un comprobador de sintaxis
Los comprobadores de sintaxis son útiles en cuatro situaciones: cuando recibes JavaScript de un tercero (un archivo generado, un fragmento de documentación o código pegado por un colega), cuando depuras un script que falla silenciosamente en una build minificada, cuando escribes JavaScript en un editor sin soporte de language server, y cuando quieres una verificación rápida antes de confirmar un archivo que has editado intensivamente.
Qué detecta y qué no detecta un comprobador de sintaxis
| Comprobación | Validador de sintaxis | ESLint | Compilador TypeScript |
|---|---|---|---|
| Corchete/llave de cierre ausente | ✓ Sí | ✓ Sí | ✓ Sí |
| Token inesperado / sintaxis incorrecta | ✓ Sí | ✓ Sí | ✓ Sí |
| Referencia a variable no definida | ✗ No | ✓ Con regla no-undef | ✓ Sí (estricto) |
| Desajuste de tipos | ✗ No | ✗ No | ✓ Sí |
| Aviso de variable sin usar | ✗ No | ✓ no-unused-vars | ✓ noUnusedLocals |
| Await ausente en llamada asíncrona | ✗ No | ✓ no-floating-promises | ✓ Sí |
| Lógica / salida incorrecta | ✗ No | ✗ No | ✗ No |
El Validador de sintaxis de JavaScript de Aback Tools se ejecuta por completo en tu navegador - pega tu código, pulsa validar y cada error de sintaxis se resalta con número de línea y mensaje del parser en menos de un segundo. Tu código nunca se sube a un servidor, lo que lo hace seguro para scripts propietarios, herramientas internas y código de aplicación confidencial.
Validador de sintaxis de JavaScript
Comprueba código JavaScript en busca de errores de sintaxis al instante - parser local en el navegador, diagnósticos por línea, sin subidas.
Errores en tiempo de ejecución y stack traces
Los errores en tiempo de ejecución llegan como una excepción lanzada con un tipo, un mensaje y un stack trace. Leerlos con eficiencia es una habilidad que separa a los depuradores rápidos de los lentos. El tipo de error acota la causa de inmediato; el stack trace apunta a la ruta de ejecución exacta que llevó hasta allí.
Cómo leer un stack trace de JavaScript
Un stack trace es una lista de llamadas a funciones en orden inverso - la llamada más reciente arriba, el punto de entrada abajo. Cada línea muestra un nombre de función, una ruta de archivo y un número `line:column`. Empieza en la parte superior del trace y desciende hasta encontrar la primera línea que referencia tu propio código (no una librería como React, Express o lodash). Esa es la llamada que desencadenó el error. Las líneas por encima muestran cómo llegaste allí.
TypeError: Cannot read properties of undefined (reading 'name')
at formatUser (app.js:24:18) // ← tu código - empieza aquí
at renderCard (components.js:51:5) // ← tu código - cadena de llamadas
at Array.map (<anonymous>)
at buildList (components.js:44:20)
at App (app.js:12:15)
at React.createElement ...La primera línea nombra el tipo de error (`TypeError`) y la propiedad específica que falló (`name`). La línea `app.js:24:18` es donde ocurrió el acceso a la propiedad. Ve a esa línea - `user.name` donde `user` es undefined - y añade el guardia apropiado: encadenamiento opcional (`user?.name`), una comprobación de nulos o un valor por defecto. El Explicador de stack traces de JavaScript analiza cualquier stack trace y produce automáticamente un desglose estructurado del origen, la cadena de llamadas y la corrección más probable.
Decodificar mensajes de error crípticos
Algunos mensajes de error en tiempo de ejecución son directos; otros son famosos por no ayudar. `"Maximum call stack size exceeded"` significa recursión infinita. `"Cannot set properties of null"` significa que llamaste a `.setAttribute()` o similar sobre un elemento del DOM que aún no existe. `"$ is not defined"` en un contexto de navegador significa que jQuery no se cargó antes del script que lo usa. El Decodificador de errores en tiempo de ejecución de JavaScript acepta cualquier mensaje de error y devuelve una explicación en lenguaje claro con pasos de corrección específicos para los patrones más comunes.
Tip
Decodificador de errores en tiempo de ejecución de JavaScript
Pega cualquier mensaje de error de JavaScript y obtén una explicación en lenguaje claro con recomendaciones de corrección concretas - sin configurar ningún entorno.
ESLint y análisis estático
ESLint es la herramienta de análisis estático estándar de la industria para JavaScript y TypeScript. Lee tu código fuente sin ejecutarlo y aplica un conjunto de reglas configurable que detecta problemas que van desde errores de sintaxis hasta antipatrones de seguridad. A diferencia de un comprobador de sintaxis, ESLint entiende el ámbito, los ciclos de vida de variables y los grafos de imports - lo que le permite encontrar bugs invisibles para un parser puro.
Qué detecta ESLint que los comprobadores de sintaxis pasan por alto
- Variables no definidas: La regla `no-undef` marca cualquier variable usada sin declaración en el ámbito.
- Variables sin usar: `no-unused-vars` previene la acumulación de código muerto que oscurece la lógica real.
- Igualdad insegura: `eqeqeq` impone `===` en lugar de `==`, eliminando bugs de coerción de tipos.
- Await ausente: `no-floating-promises` (vía TypeScript ESLint) detecta llamadas asíncronas sin gestionar.
- Código inalcanzable: `no-unreachable` marca sentencias después de un `return` o `throw`.
- No-console en producción: `no-console` evita que logs de depuración lleguen a producción.
- Reglas de seguridad: `eslint-plugin-security` marca vulnerabilidades potenciales de inyección y regex inseguros.
Fundamentos de la configuración de ESLint
El comportamiento de ESLint está dirigido por completo por su archivo de configuración - `.eslintrc.json`, `.eslintrc.js` o el nuevo formato flat config `eslint.config.js`. La configuración declara qué conjuntos de reglas extender (`eslint:recommended`, `plugin:@typescript-eslint/recommended`, `plugin:react/recommended`) y qué reglas individuales habilitar, deshabilitar o ajustar. Un archivo de ESLint mal configurado puede deshabilitar silenciosamente reglas importantes, por eso validar la propia configuración importa. El Validador de configuración ESLint comprueba tu archivo de configuración en busca de errores estructurales y conflictos de reglas antes de ejecutar una pasada de lint.
El valor de ESLint no está en las reglas que habilitas - está en las reglas que tu equipo acuerda aplicar de forma consistente. Una configuración compartida en el control de versiones garantiza que cada desarrollador vea el mismo feedback.
Ejecutar ESLint por primera vez
# Instalar ESLint en un proyecto
npm install --save-dev eslint
# Inicializar un archivo de configuración de forma interactiva
npx eslint --init
# Analizar un solo archivo
npx eslint src/app.js
# Analizar un directorio y auto-corregir problemas seguros
npx eslint src/ --fix
# Salida JSON para herramientas de CI
npx eslint src/ --format json > eslint-report.jsonNote
Depuración con DevTools del navegador
Chrome DevTools, Firefox Developer Tools y Safari Web Inspector ofrecen la experiencia de depuración de JavaScript más profunda disponible - ejecución en vivo, breakpoints, inspección de variables y rastreo de peticiones de red. Para errores en tiempo de ejecución difíciles de reproducir localmente, DevTools es el entorno de investigación principal.
El panel Consola
La pestaña Consola muestra cada mensaje registrado, advertencia y error lanzado en tiempo real. Los errores aparecen en rojo con un stack trace expandible. Pulsar la referencia archivo:línea a la derecha salta directamente al panel Sources en esa ubicación. El Clasificador de errores de consola del navegador complementa DevTools categorizando los errores de consola por tipo y severidad - útil cuando tienes una salida de consola larga y necesitas priorizar rápidamente.
Breakpoints y el panel Sources
El panel Sources permite fijar breakpoints - pausar la ejecución en una línea específica e inspeccionar cada variable en el ámbito en ese momento. Pulsa el número de línea en el panel Sources para añadir un breakpoint y luego recarga la página o dispara la acción que causa el error. Cuando la ejecución se pausa, pasa el ratón sobre cualquier variable para ver su valor actual, usa el panel Call Stack para ver cómo llegaste allí y avanza por el código línea a línea con F10 (paso a paso por encima) o F11 (entrar).
Breakpoints condicionales y logpoints
Pulsa con el botón derecho sobre cualquier número de línea en Sources para añadir un breakpoint condicional (pausa solo cuando una condición es verdadera, p. ej. `user.id === 42`) o un logpoint (registra un valor sin pausar, como un `console.log` no invasivo). Ambos son sumamente útiles para depurar bucles y manejadores de eventos donde pausar en cada iteración sería poco práctico.
| Enfoque de depuración | Mejor para | Detecta errores de ejecución | Detecta errores de sintaxis |
|---|---|---|---|
| Validador de sintaxis de JavaScript | Comprobación estática previa a la ejecución | ✗ No | ✓ Sí |
| ESLint | Análisis estático, CI/CD | ⚠ Algunos | ✓ Sí |
| Consola de DevTools del navegador | Errores en vivo del navegador | ✓ Sí | ✓ Sí |
| Breakpoints de DevTools | Depuración interactiva | ✓ Sí | ✗ No |
| Decodificador de errores en ejecución | Explicar mensajes de error | ✓ Sí | ✗ No |
| Explicador de stack traces | Rastrear el origen de la llamada | ✓ Sí | ✗ No |
| Node.js --inspect + Chrome | Depuración del lado servidor | ✓ Sí | ✓ Sí |
Comprobación de errores en CI/CD
La comprobación manual de errores durante el desarrollo es una buena práctica pero no una garantía. Automatizar la comprobación de errores de JavaScript en tu pipeline de CI/CD garantiza que ningún error de sintaxis, infracción de ESLint o error de tipo pueda fusionarse en la rama principal - sin importar qué desarrollador envió el pull request o si ejecutó las comprobaciones localmente.
Una puerta de calidad de CI mínima
name: JavaScript Quality
on:
pull_request:
paths: ['src/**/*.js', 'src/**/*.ts']
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- name: ESLint
run: npx eslint src/ --max-warnings 0
- name: TypeScript check
run: npx tsc --noEmitLa bandera `--max-warnings 0` trata las advertencias de ESLint como errores, bloqueando la fusión. Combínalo con `tsc --noEmit` para proyectos TypeScript y detectar errores de tipo que las reglas de ESLint no pueden ver. Ambos pasos salen con código distinto de cero en caso de fallo, lo que hace fallar el workflow de GitHub Actions e impide que el pull request se fusione hasta resolver los problemas.
Source maps para el seguimiento de errores en producción
Cuando un error de JavaScript llega a producción en un bundle minificado, el stack trace muestra nombres de archivo comprimidos y números de columna que son inútiles sin un source map. Los source maps vinculan la salida minificada con los archivos fuente originales. Antes de desplegar, valida que tus archivos de source map estén correctamente estructurados con el Validador de source maps - un source map roto produce stack traces de producción ilegibles que ralentizan considerablemente el diagnóstico de incidentes.
Warning
Buenas prácticas de depuración
Buenos hábitos de comprobación de errores reducen el tiempo de depuración en órdenes de magnitud. Estas prácticas aplican sin importar si trabajas en un navegador, un servicio de Node.js o una función serverless.
Corrige el primer error, no todos los errores
Los errores de sintaxis de JavaScript se cascadan - un corchete ausente en la línea 10 puede producir cinco errores notificados por debajo a medida que el parser pierde la noción de la estructura del documento. Corrige siempre primero el error más alto notificado y luego vuelve a ejecutar el validador. Lo que parecían cinco bugs suele ser uno. Esto aplica igualmente a los informes de ESLint y a la salida del compilador de TypeScript.
Usa modo estricto y características modernas del lenguaje
Añadir `"use strict"` a un archivo (o usar módulos ES, que siempre son estrictos) convierte fallos silenciosos en errores lanzados. Asignar a una variable no declarada crea silenciosamente una global en modo laxo; en modo estricto lanza un `ReferenceError` de inmediato. El encadenamiento opcional (`?.`), el coalescente nulo (`??`) y los valores por defecto en destructuring de arrays (`const [a = 0] = arr`) reducen significativamente la superficie de los errores `TypeError: Cannot read properties of undefined`.
Valida los datos externos en la frontera
La mayoría de las excepciones `TypeError` en tiempo de ejecución en producción provienen de datos externos - respuestas de API, entrada de usuario o valores de localStorage - que no coinciden con la forma esperada. Valida los datos entrantes en la frontera: usa un validador de esquemas como Zod o Joi sobre las respuestas de API, comprueba los valores de `localStorage` antes de parsearlos como JSON y nunca asumas que un campo existe solo porque estaba en tus datos de prueba. La Calculadora de tamaño de heap de JavaScript es útil cuando aparecen errores de memoria - ayuda a estimar si una estructura de datos grande o un proceso de larga duración está excediendo la asignación de heap de V8.
- Corrige primero el primer error: Los errores de sintaxis se cascadan - un problema real produce varios notificados.
- Habilita ESLint en tu editor: El feedback en línea en tiempo real detecta errores mientras escribes, no tras el commit.
- Usa TypeScript: Los errores de tipo capturados en compilación no pueden convertirse en errores de ejecución en producción.
- Valida los datos externos: Las respuestas de API y la entrada de usuario deben comprobarse antes de usarse, no asumirse correctas.
- Escribe tests enfocados: Los tests unitarios de rutas críticas sacan a la luz errores de lógica que ninguna herramienta estática puede detectar.
- Usa source maps: Los stack traces legibles de producción reducen drásticamente el tiempo de respuesta a incidentes.
Tip
Key takeaways
- Los errores de sintaxis se detectan antes de la ejecución - usa el Validador de sintaxis de JavaScript para una comprobación instantánea, local en el navegador y sin subida de código.
- Los errores en tiempo de ejecución producen un tipo y un stack trace - el Decodificador de errores en tiempo de ejecución de JavaScript explica cualquier mensaje de error en lenguaje claro con pasos de corrección.
- ESLint detecta problemas que los comprobadores de sintaxis pasan por alto: variables no definidas, igualdad insegura, imports sin usar y `await` ausentes - valida tu configuración ESLint con el Validador de configuración ESLint.
- Corrige siempre primero el error más alto notificado - los errores de sintaxis se cascadan y un problema real produce varios notificados.
- Añade ESLint y `tsc --noEmit` a tu pipeline de CI/CD para que ningún error pueda fusionarse sin ser detectado, sin importar la configuración local.
- Los source maps son esenciales para stack traces de producción legibles - validalos con el Validador de source maps antes del despliegue.
- Valida los datos externos (respuestas de API, entrada de usuario) en la frontera para eliminar la principal causa de `TypeError: Cannot read properties of undefined` en producción.