Problemi

Ogni progetto porta già con sé uno strumento che dice cosa non va — tsc, dart analyze, ESLint, Clippy, go vet, Ruff. Quello che nessuno dice è se sia il tuo diff ad aver introdotto i quaranta avvisi appena stampati. Gitcito sa quali file sono sporchi, quindi la stessa lista risponde a quella domanda con un interruttore.

La barra di stato porta il conteggio — errori, avvisi, informazioni: le tre cifre che VS Code ha insegnato a leggere a tutti. Un clic (o Problemi nella palette dei comandi) apre il pannello in basso, raggruppato per file. Cliccare una riga apre il file esattamente lì. Prima della prima scansione mostra trattini invece di zeri: nessuno ha ancora guardato, e tre zeri direbbero il contrario.

Cosa esegue

Flutter rientra nella riga di Dart: un’app Flutter è un progetto Dart, e flutter analyze chiama lo stesso analizzatore di dart analyze.

Il progetto non deve stare per forza nella radice. Quei marcatori vengono cercati anche qualche livello più in basso, quindi un’app Flutter in mobile/ o un pacchetto in apps/web viene trovato, e ogni analizzatore gira nella directory del proprio progetto. Un progetto annidato dello stesso tipo viene saltato quando un antenato lo copre già — è esattamente ciò che dice un tsconfig.json nella radice — e una scansione si ferma a dodici progetti, perché un monorepo non deve avviare cinquanta compilatori.

Un binario in node_modules/.bin batte quello nel PATH, esattamente come lo risolvono gli script del progetto. Tutto gira in parallelo e l’output di ogni strumento viene ricondotto a una sola forma, deduplicato e ordinato: due analizzatori che segnalano la stessa riga producono una riga sola.

Niente parte da solo. tsc --noEmit su un repository grande sono decine di secondi, e questi comandi sono la toolchain del repository, non di Gitcito. Partono quando apri il pannello o premi aggiorna, mai da soli. È anche il motivo per cui la lista è un’istantanea: modifica un file e resta vecchia finché non la rilanci.

Impostazioni → Generale → Analizzatori di codice decide quanto è solerte: scansione all’apertura del pannello (predefinito), solo premendo aggiorna, o disattivato — il che nasconde del tutto la metà analizzatori, il suo contatore nella barra di stato e il suo comando.

L’output generato viene scartato. Uno strumento puntato sulla radice del progetto analizza tutto ciò che trova, e ciò include .next/build/chunks, un dist impacchettato, una copia vendorizzata — centinaia di lamentele su codice scritto da una macchina che seppelliscono le poche sul tuo. Gitcito chiede a git quali file sono ignorati e scarta quelli, ma mai un file tracciato: committare l’output generato è una scelta, e git check-ignore la rispetta. node_modules se ne va comunque.

Solo ciò che hai cambiato

L’interruttore nell’intestazione scarta ogni problema in un file che non hai toccato. È la vista che vale la pena tenere aperta: una lista piatta di tutti gli avvisi di un codice diventa carta da parati in una settimana, mentre "li ha aggiunti questo diff?" è una domanda a cui rispondere prima del commit.

Anche i chip di gravità filtrano. Spenti significano mostra tutto; accenderne uno restringe a quello.

I limiti

• Nessun language server. Questa è una scansione, non un demone: niente sottolineature mentre scrivi, nessun risultato prima di chiederlo.
• Uno strumento non installato viene nominato, non nascosto. Il piè di pagina dice cosa non è stato possibile eseguire, perché una lista vuota senza spiegazione è peggio di una corta con un motivo.
• Si capisce solo l’output leggibile dalla macchina. Ogni analizzatore viene letto dal suo formato macchina documentato; uno strumento configurato per stampare altro qui è invisibile.
• Cinquemila problemi è il tetto. Oltre, il pannello lo dice e si ferma — un repository in quello stato ha un problema più grosso di una barra di scorrimento.

Vedi anche: CI locale · Terminale integrato