Validador JavaScript
Nombra la línea, no solo el error

Qué comprueba un validador JavaScript

Un motor lee un script entero antes de ejecutar una sola línea. Por lo tanto, un corchete roto en cualquier parte detiene el archivo, y la pestaña se queda en blanco.

Para ese fallo existe este validador JavaScript. Recorre el script como texto e informa del primer lugar donde se rompe la gramática, con la línea y la columna.

Además, comprueba la forma de lo que ha leído. Una llave sin pareja, una cadena que nunca cierra, una palabra clave usada como nombre, una coma suelta dentro de la lista de argumentos de una llamada.

No construye ningún contexto de ejecución, así que no crea ninguna global ni llama a ninguna función. Porque el lector solo lee el script, puedes apuntar un validador a código que nunca ejecutarías en una página propia.

Nada sale de esta pestaña. Por eso un script de cliente bajo acuerdo de confidencialidad se lee igual que uno público.

Cómo lee un script un validador JavaScript

La primera pasada convierte el texto en tokens. Un número, una cadena, una plantilla, una expresión regular, un nombre, un operador y una palabra clave son cosas distintas, y el lector decide cuál está mirando carácter a carácter.

Luego la segunda pasada recorre esos tokens en orden y comprueba la forma de lo que lee: qué corchetes siguen abiertos, qué nombres guarda ya un ámbito y si una palabra como return tiene una función alrededor. El reglamento aquí es ECMA-262, el estándar detrás de todos los motores.

El orden importa, y explica un número sorprendente de mensajes de error. Porque la tokenización va primero, un script que parece tener un problema de corchetes puede tener en realidad una comilla que nunca cerró.

Un caso pide una segunda mirada en lugar de una regla: una barra es un operador de división o el inicio de una expresión regular, y la respuesta depende del token anterior. Por eso el tokenizador pregunta al último token qué era.

Las plantillas añaden un pliegue más. Porque una plantilla puede contener una expresión dentro de llaves, el tokenizador mantiene una pila de la plantilla en la que está. Así una llave en una cadena es texto, y una llave dentro de una plantilla es código.

Por qué un script válido puede seguir estando mal

Gramática y significado son capas separadas. Un validador responde a la pregunta de la gramática, y todos los útiles se detienen ahí.

Así, un script puede pasar con una variable que nunca se declara en modo estricto, una propiedad leída de un valor que en ese momento contiene undefined, o un await dentro de una función que no es asíncrona. Cada uno de esos es un problema de ejecución.

La línea entre ambos merece recordarse. Un error de sintaxis significa que ninguna parte del archivo se ejecutó, y un error de ejecución significa que el archivo corrió hasta esa línea. Por eso los dos piden una depuración completamente distinta.

Por eso también esta página nombra el primer error en lugar de cien. Porque el análisis se detiene ahí, todo lo que viene después es conjetura, y una lista de conjeturas vale menos que un hecho.

Las seis comprobaciones y qué significa cada una

La primera comprobación es el equilibrio de corchetes. El lector informa de una llave, un corchete o un paréntesis sin pareja en el punto donde se rindió. De hecho, este es el único fallo que puede costar el archivo entero.

La segunda es una cadena o plantilla sin cerrar. Porque el tokenizador se traga todo lo que sigue a una comilla de apertura, la nota nombra tanto la comilla como el final del archivo donde paró la búsqueda.

La tercera es un token que la gramática no permite. Dos operadores seguidos, una coma en el lugar equivocado, o una flecha sin nada delante. Así cada uno viene con el token en cuestión.

La cuarta es una palabra clave mal usada como nombre. Por eso el lector rechaza una asignación a una palabra reservada, y una variable nombrada con una, antes de que algo se ejecute.

La quinta es un duplicado en un mismo ámbito. Dos parámetros con el mismo nombre, o un let que repite un nombre ya declarado en el mismo bloque. Porque el segundo gana en el primer caso y lanza en el segundo, el lector nombra los dos.

La sexta es un return fuera de una función, y sus parientes. Un break sin bucle, un case sin switch y un yield sin generador. Así, esos pertenecen a una posición y a ninguna otra.

Lo que esta página no hará

No ejecutará tu script. Nada aquí crea una función, asigna una variable o arranca un temporizador, así que nada puede actuar en la página mientras lees.

No informará de un error de ejecución, un error de tipo o una llamada de red fallida. Porque esos necesitan un motor, y un motor es lo que ya tienes en la pestaña de al lado.

No corregirá el código. Una conjetura sobre el corchete que falta es una nota, no una edición, porque una corrección automática puede convertir un error claro en un cambio silencioso de comportamiento.

No comprobará tipos. Un archivo con una anotación de tipo lleva más que JavaScript, así que pega la salida de tu compilador y no su entrada.