Validatore JavaScript
Indica la riga, non solo l’errore

Che cosa controlla un validatore JavaScript

Un motore legge uno script intero prima di lanciarne una sola riga. Di conseguenza una parentesi rotta in qualsiasi punto ferma il file, e la scheda resta bianca.

È per questo guasto che esiste questo validatore JavaScript. Percorre lo script come testo e segnala il primo punto in cui la grammatica si rompe, con la riga e la colonna.

Inoltre controlla la forma di quello che ha letto. Una graffa senza compagna, una stringa che non chiude mai, una parola chiave usata come nome, una virgola smarrita nella lista di argomenti di una chiamata.

Non costruisce nessun contesto di esecuzione, così non crea nessuna variabile globale e non chiama nessuna funzione. Perché il lettore legge soltanto lo script, potete puntare un validatore su codice che non lancereste mai su una pagina vostra.

Niente lascia questa scheda. Per questo uno script di un cliente sotto accordo di riservatezza viene letto esattamente come uno pubblico.

Come un validatore JavaScript legge uno script

La prima passata trasforma il testo in token. Un numero, una stringa, un template, un’espressione regolare, un nome, un operatore e una parola chiave sono cose diverse, e il lettore decide carattere per carattere quale sta guardando.

Poi la seconda passata percorre quei token in ordine e controlla la forma di ciò che legge: quali parentesi restano aperte, quali nomi un ambito tiene già e se una parola come return ha una funzione attorno. Il regolamento qui è ECMA-262, lo standard dietro ogni motore.

L’ordine conta, e spiega un numero sorprendente di messaggi di errore. Perché la divisione in token viene prima, uno script che sembra avere un problema di parentesi spesso ha invece una virgoletta che non ha mai chiuso.

Un caso chiede un secondo sguardo invece di una regola: una barra è un operatore di divisione oppure l’inizio di un’espressione regolare, e la risposta dipende dal token precedente. Per questo il tokenizzatore chiede all’ultimo token che cosa fosse.

I template aggiungono un’altra piega. Perché un template può contenere un’espressione fra graffe, il tokenizzatore tiene una pila del template in cui si trova. In questo modo una graffa in una stringa è testo, e una graffa dentro un template è codice.

Perché uno script valido può essere comunque sbagliato

Grammatica e significato sono due strati separati. Un validatore risponde alla domanda della grammatica, e ogni validatore utile si ferma lì.

Così uno script passa con una variabile mai dichiarata in modalità strict, con una proprietà letta da un valore che in quel momento contiene undefined, oppure con un await dentro una funzione che non è asincrona. Ognuno di questi è un problema di esecuzione.

Il confine fra i due vale la pena di ricordarlo. Un errore di sintassi significa che nessuna parte del file è girata, e un errore di esecuzione significa che il file è girato fino a quella riga. Perciò i due chiedono un debug completamente diverso.

Per questo la pagina nomina il primo errore invece di cento. Perché l’analisi si ferma lì, tutto quello che segue è un indovinello, e una lista di supposizioni pesa meno di un fatto.

I sei controlli e che cosa significa ciascuno

Il primo controllo è l’equilibrio delle parentesi. Il lettore segnala una graffa, una quadra o una tonda senza compagna nel punto in cui ha rinunciato. Infatti questo è l’unico guasto che costa il file intero.

Il secondo è una stringa o un template non chiuso. Perché il tokenizzatore inghiotte tutto quello che segue una virgoletta di apertura, la nota nomina sia la virgoletta sia la fine del file dove la ricerca si è fermata.

Il terzo è un token che la grammatica non permette. Due operatori di fila, una virgola nel posto sbagliato, oppure una freccia senza nulla davanti. Così ognuno arriva con il token stesso.

Il quarto è una parola chiave usata male come nome. Per questo il lettore rifiuta un’assegnazione a una parola riservata, e una variabile che ne porta il nome, prima che qualcosa giri.

Il quinto è un duplicato in uno stesso ambito. Due parametri con lo stesso nome, oppure un let che ripete un nome già dichiarato nello stesso blocco. Perché nel primo caso vince il secondo e nel secondo solleva un errore, il lettore li nomina entrambi.

Il sesto è un return fuori da una funzione, e i suoi parenti. Un break senza ciclo, un case senza switch e un yield senza generatore. Quindi questi stanno in una posizione e in nessun’altra.

Quello che questa pagina non farà

Non lancerà il vostro script. Niente qui crea una funzione, assegna una variabile o avvia un timer, quindi niente può agire sulla pagina mentre leggete.

Non segnalerà un errore di esecuzione, un errore di tipo o una chiamata di rete fallita. Perché quelli richiedono un motore, e un motore lo avete già nella scheda accanto.

Non correggerà il codice. Una supposizione sulla parentesi mancante è una nota, non una modifica, perché una correzione automatica può trasformare un errore chiaro in un cambio di comportamento silenzioso.

Non controllerà i tipi. Un file con un’annotazione di tipo porta più di JavaScript, quindi incollate l’uscita del vostro compilatore invece del suo ingresso.