Het TypeScript-team heeft een nieuwe compiler-flag uitgebracht in de 6.0-release – --noPropertyAccessFromIndexSignature. Wanneer deze is ingeschakeld, weigert de compiler toegang via dot-notatie tot eigenschappen die afkomstig zijn van een index signature, waardoor ontwikkelaars worden gedwongen om bracket-notatie te gebruiken. Hierdoor worden potentiële undefined-waarden zichtbaar tijdens het compileren in plaats van in productie.

Waarom deze flag belangrijk is

In JavaScript dienen objecten vaak als dictionaries, en TypeScript stelt je in staat om dergelijke structuren te typen met een index signature, bijvoorbeeld Record<string, T>. De taal behandelt obj.key en obj["key"] als uitwisselbaar, waardoor de compiler ervan uitgaat dat de eigenschap bestaat, zelfs wanneer de key pas tijdens runtime bekend is. Die stille aanname is de bron van veel crashes: code die obj.missingProp aanroept, compileert probleemloos, draait, en gooit vervolgens een fout omdat de waarde undefined is.

Dot-notatie bevat een impliciete garantie – het vertelt lezers en de type checker dat de eigenschap zeker aanwezig is. Bracket-notatie signaleert daarentegen onzekerheid – de key kan ontbreken en het resultaat kan undefined zijn. --noPropertyAccessFromIndexSignature dwingt dit visuele en semantische onderscheid af, waardoor een hele klasse aan runtime-fouten wordt omgezet in compile-time diagnostiek.

Hoe de flag werkt

Wanneer de flag is ingeschakeld, wordt elke expressie die via dot-notatie toegang probeert te krijgen tot een eigenschap via een index signature gemarkeerd als een fout. De code moet worden herschreven om brackets te gebruiken:

// Before
const name = userData.name;          // OK even if "name" is not in the index

// After enabling the flag
const name = userData["name"];       // Error unless brackets are used

De compiler past vervolgens dezelfde regels voor undefined-afhandeling toe die hij al gebruikt voor bracket-toegang. Als --noUncheckedIndexedAccess ook is ingeschakeld, wordt het type van userData["name"] de T | undefined, wat de ontwikkelaar dwingt om de ontbrekende waarde te controleren.

Praktische migratiestappen

  1. Schakel de flag in in tsconfig.json:

    {
  "compilerOptions": {
    "noPropertyAccessFromIndexSignature": true
  }
}

  2. Voer de type checker uit. Alle dot-notatie-toegangen tot index-signature keys zullen als fouten verschijnen.

  3. Vervang punten door brackets. De wijziging is mechanisch; het heeft geen invloed op de runtime-prestaties.

  4. Ga aan de slag met de resulterende undefined-types. Voeg nullish coalescing, optional chaining of expliciete controles toe waar nodig.

  5. Overweeg om deze te combineren met --noUncheckedIndexedAccess voor het sterkste vangnet. Samen zorgen ze ervoor dat elke toegang in dictionary-stijl wordt behandeld als potentieel afwezig.

Wanneer je expliciete eigenschappen moet behouden

Als een veld deel uitmaakt van een stabiel API-contract, declareer het dan als een expliciete eigenschap in plaats van te vertrouwen op een index signature. Expliciete eigenschappen staan dot-notatie toe, waardoor de garantie behouden blijft dat het veld altijd aanwezig zal zijn (voor zover het type-systeem dit kan verifiëren). Reserveer index signatures voor echt dynamische gegevens waarbij de keys niet vooraf bekend zijn.

Tegenargument: extra verbositeit

Sommige teams kunnen de extra brackets als 'ruis' ervaren, vooral in codebases die veel gebruikmaken van flexibele objecten. De flag dwingt een striktere discipline af die een aanzienlijke refactor kan vereisen voor legacy-projecten. In die gevallen kan de flag stapsgewijs worden ingevoerd, bijvoorbeeld beperkt tot nieuwe modules, terwijl de rest van de codebase het patroon in de loop van de tijd overneemt.

Waar je op moet letten

De flag maakt deel uit van een bredere beweging in TypeScript 6.0 naar striktere type safety. Toekomstige releases kunnen extra controles introduceren rond object spread, optional chaining of het gebruik van geïnferreerd any. Door de TypeScript-roadmap in de gaten te houden, kunnen teams beslissen wanneer ze de volgende set veiligheidsfuncties implementeren zonder de leveringsschema's te verstoren.

Kernpunt: Het inschakelen van --noPropertyAccessFromIndexSignature maakt het onderscheid tussen "deze eigenschap is gegarandeerd" en "deze eigenschap kan ontbreken" expliciet in de code, waardoor een hele klasse aan bugs wordt opgevangen voordat ze in productie komen. Een stille runtime-fout omzetten in een compile-time fout is een kleine wijziging met een onevenredig grote impact op de betrouwbaarheid.