Antwoord.

Achtergrond

TypeScript is oorspronkelijk ontwikkeld om een zo soepel mogelijke overgang van JavaScript mogelijk te maken, zodat variabelen of parameters zonder expliciet gespecificeerd type standaard het type any kregen. Dit vergemakkelijkte de migratie, maar verminderde de voordelen van statische typing. Om de betrouwbaarheid en voorspelbaarheid van de code te verhogen, heeft het TypeScript-team de compiler-vlag noImplicitAny geïntroduceerd, die vereist dat je expliciet types opgeeft of TypeScript in staat stelt ze correct af te leiden.

Probleem

Wanneer noImplicitAny is uitgeschakeld, kunnen ontwikkelaars per ongeluk vergeten expliciet een type voor een variabele, parameter of retourwaarde van een functie op te geven. Dit maakt de code minder veilig en bemoeilijkt refactoring: eventuele typefouten worden niet tijdens de compilatie gedetecteerd, maar komen alleen tijdens de uitvoering naar voren.

Oplossing

Het inschakelen van noImplicitAny in het tsconfig.json-bestand dwingt de TypeScript-compiler om een fout te genereren bij elk impliciet gebruik van het type any. Dit vereist van ontwikkelaars dat ze aandacht besteden aan types, maakt refactoringprocessen minder risicovol en de code betrouwbaarder.

Codevoorbeeld:

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

// Voorbeeldfunctie zonder type-aanduiding voor parameter
function printUser(user) {
  console.log(user.name); // Compilatiefout als type niet is gespecificeerd
}

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

Belangrijkste kenmerken:

Vereist expliciete type-aanduidingen op alle onduidelijke plaatsen.
Staat toe om het grootste deel van typefouten tijdens de compilatie te detecteren.
Zorgt voor hoge voorspelbaarheid en veiligheid van de code in grote projecten.

Vragen met een twist.

Verhindert het inschakelen van noImplicitAny altijd alle potentiële typefouten in het project?

Nee, deze vlag elimineert alleen impliciete any. Expliciet gebruik van any is nog steeds toegestaan. Voor volledige bescherming moet ook expliciete any worden beperkt via linting en review.

Als het type automatisch wordt afgeleid, geeft noImplicitAny dan nog steeds een fout?

Nee, als TypeScript het type correct kan afleiden (bijvoorbeeld door initialisatie), is er geen fout. Bijvoorbeeld:

let n = 123; // Type number, niet any

Schakelt het inschakelen van strict automatisch noImplicitAny in?

Ja, de vlag strict schakelt veel strikte controles in, waaronder noImplicitAny. Maar het kan handmatig worden uitgeschakeld indien nodig.

Typische fouten en anti-patronen

Het laten staan van expliciete any op veel plaatsen - hierdoor verliest strikte typing zijn betekenis.
In grote codebasissen het project zonder noImplicitAny uitvoeren, vertrouwend op "het zal wel goedkomen" - veel verborgen fouten.
Types "op een of andere manier toevoegen, zodat het compileert", zonder na te denken over de nauwkeurigheid.

Voorbeeld uit de praktijk

Negatief geval

In het project is noImplicitAny uitgeschakeld, de meeste API-handlers accepteren parameters zonder expliciete types. Bij het implementeren van nieuwe businesslogica maken ontwikkelaars fouten in eigenschapsnamen, maar fouten komen pas aan het licht in productie.

Voordelen:

Eenvoudige en snelle start van de code.
Gemakkelijker migreren van JS.

Nadelen:

In productie komen fouten voor die statisch gevonden hadden kunnen worden.
Refactoring en opschaling worden bemoeilijkt.

Positief geval

Na het inschakelen van noImplicitAny werd de hele code geleidelijk herfaced, impliciete any's werden verwijderd. Er werd begonnen met het gebruik van een editor met type-h highlighting en autocompletion. Nieuwe fouten worden onmiddellijk op het niveau van de build opgelost.