Risposta.

Storia della questione

TypeScript è stato originariamente sviluppato con la possibilità di un passaggio fluido da JavaScript, quindi per impostazione predefinita variabili o parametri senza un tipo chiaramente specificato ricevevano il tipo any. Questo semplificava la migrazione, ma riduceva i vantaggi della tipizzazione statica. Per aumentare l'affidabilità e la prevedibilità del codice, il team di TypeScript ha introdotto il flag del compilatore noImplicitAny, che richiede di specificare esplicitamente i tipi o di consentire a TypeScript di dedurli correttamente.

Problema

Quando noImplicitAny è disattivato, gli sviluppatori possono accidentalmente omettere di specificare esplicitamente il tipo di una variabile, parametro o valore di ritorno di una funzione. Questo rende il codice meno sicuro e complica il refactoring: eventuali errori relativi ai tipi non vengono rilevati durante la compilazione, ma si manifestano solo durante l'esecuzione.

Soluzione

Attivare noImplicitAny nel file tsconfig.json fa sì che il compilatore TypeScript generi un errore per ogni utilizzo implicito del tipo any. Ciò richiede agli sviluppatori di prestare attenzione ai tipi, rende i processi di refactoring meno rischiosi e il codice stesso più affidabile.

Esempio di codice:

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// Esempio di funzione senza specificare il tipo del parametro
function printUser(user) {
  console.log(user.name); // Errore di compilazione se il tipo non è specificato
}

// Corretto:
function printUser(user: { name: string }) {
  console.log(user.name);
}

Caratteristiche chiave:

Richiede di specificare esplicitamente i tipi in qualsiasi luogo ambiguo.
Permette di identificare la maggior parte degli errori di tipo durante la compilazione.
Garantisce un'elevata prevedibilità e sicurezza del codice in grandi progetti.

Domande trabocchetto.

L'attivazione di noImplicitAny previene sempre tutti i potenziali errori di tipo nel progetto?

No, questo flag elimina solo gli any impliciti. L'uso esplicito di any è comunque consentito. Per una protezione completa, vale la pena limitare anche gli any espliciti tramite linting e revisione.

Se il tipo viene dedotto automaticamente, noImplicitAny dà comunque errore?

No, se TypeScript è stato in grado di dedurre correttamente il tipo (ad esempio, dall'inizializzazione), non ci sarà errore. Ad esempio:

let n = 123; // Tipo number, non any

L'attivazione di strict attiva automaticamente noImplicitAny?

Sì, il flag strict attiva numerosi controlli rigorosi, inclusi noImplicitAny. Ma può essere disattivato manualmente se necessario.

Errori comuni e anti-pattern

Lasciare any esplicito in molti luoghi - si perde il senso della tipizzazione rigorosa.
In un grande codice non avviare il progetto con noImplicitAny, fidandosi di "chissà" - molteplici errori nascosti.
Aggiungere tipi "in qualche modo, purché compili", senza pensare alla correttezza.

Esempio dalla vita reale

Caso negativo

Nel progetto noImplicitAny è disattivato, la maggior parte dei gestori API accetta parametri senza un tipo esplicito. Durante l'implementazione di nuove logiche aziendali, gli sviluppatori commettono errori nei nomi delle proprietà, ma gli errori emergono solo in produzione.

Vantaggi:

Avvio del codice semplice e veloce.
Migrazione più facile da JS.

Svantaggi:

In produzione compaiono errori che avrebbero potuto essere scoperti staticamente.
Il refactoring e la scalabilità diventano più complicati.

Caso positivo

Dopo aver attivato noImplicitAny, tutto il codice è stato gradualmente refattorizzato, gli any impliciti sono stati eliminati. Ha iniziato a utilizzare un editor con evidenziazione dei tipi e completamento automatico. Gli errori che ricompaiono vengono immediatamente corretti durante la fase di build.