Tryb strict w TypeScript: co włącza strict: true

Tryb strict to opcja "strict": true w tsconfig.json. To jeden przełącznik dla ośmiu flag sprawdzania typów, które wyłapują niejawne any, niesprawdzone null i undefined, niebezpieczne przypisania funkcji oraz niezainicjowane pola klas. W TypeScript 7 strict jest domyślnie włączony. Tak wygląda kod, który przechodzi te sprawdzenia:

function double(x: number) { // noImplicitAny: x needs a type
  return x * 2;
}

function findUser(id: number): { name: string } | undefined {
  return id === 1 ? { name: "Ada" } : undefined;
}

const user = findUser(2);
console.log(user?.name ?? "no user"); // strictNullChecks: user may be undefined

try {
  JSON.parse("{");
} catch (err) { // useUnknownInCatchVariables: err is unknown
  console.log(err instanceof Error ? err.name : String(err));
}

console.log(double(21));

Wynik to no user, SyntaxError i 42. Usuń : number, ?. albo sprawdzenie instanceof, a plik przestanie się kompilować.

Jak go włączyć

{
    "compilerOptions": {
        "strict": true
    }
}

Pojedyncze flagi mają pierwszeństwo przed strict, w obie strony. "strict": true, "strictNullChecks": false zostawia wszystko poza sprawdzaniem null, a "strict": false, "noImplicitAny": true włącza tylko tę jedną flagę. strict oznacza też zgodę na sprawdzenia dodane w przyszłych wersjach, bo nowe flagi z rodziny strict dołączają do grupy.

strict w TypeScript nie ma nic wspólnego z dyrektywą "use strict" w JavaScript, która jest trybem działania w czasie wykonania. TypeScript 7 zawsze emituje "use strict" tam, gdzie to potrzebne, a ustawienie alwaysStrict: false to błąd TS5108 (opcję usunięto).

Co wyłapuje każda flaga

Najwięcej kodu zmieniają dwie flagi: noImplicitAny i strictNullChecks. Ten blok celowo łamie obie:

// This does not compile: two strict errors.
function double(x) {
  return x * 2;
}

function findUser(id: number): { name: string } | undefined {
  return id === 1 ? { name: "Ada" } : undefined;
}

const user = findUser(2);
console.log(user.name, double(2));

Wypisuje index.ts(2,17): error TS7006: Parameter 'x' implicitly has an 'any' type. oraz index.ts(11,13): error TS18048: 'user' is possibly 'undefined'. Bez strict ten kod się kompiluje, a potem pada w czasie wykonania z TypeError: Cannot read properties of undefined (reading 'name'). Ze strict awaria zamienia się w błąd kompilacji. Poprawki to pierwszy blok na tej stronie.

strictFunctionTypes: po co istnieje

Funkcja, która obsługuje tylko napisy, nie może być użyta tam, gdzie mogą trafić liczby. Poniższe sprawdzenie jest wyciszone przez @ts-expect-error, żeby można było je uruchomić i zobaczyć, przed czym chroni błąd:

type Handler = (value: string | number) => void;

const shout = (s: string) => console.log(s.toUpperCase());

// @ts-expect-error strictFunctionTypes rejects this assignment
const handle: Handler = shout;

try {
  handle(42); // the type allows a number, shout cannot take one
} catch (e) {
  console.log(e instanceof Error ? e.message : e); // s.toUpperCase is not a function
}

Bez komentarza przypisanie to błąd TS2322, Type '(s: string) => void' is not assignable to type 'Handler'., a po nim Types of parameters 's' and 'value' are incompatible. Celowo zostawiono jeden wyjątek: parametry metod zadeklarowanych składnią metody (handle(value: string | number): void wewnątrz interfejsu) wciąż są sprawdzane łagodniej, więc shout dałoby się przypisać do takiej metody bez błędu.

strictPropertyInitialization

Każde pole klasy musi dostać wartość w deklaracji albo w konstruktorze. Są trzy sposoby, żeby to spełnić:

class Account {
  owner: string;                  // assigned in the constructor
  balance = 0;                    // initializer
  history: string[] = [];         // initializer
  lastLogin?: Date;               // optional: may stay undefined
  sessionId!: string;             // "!": assigned later, you promise

  constructor(owner: string) {
    this.owner = owner;
  }
}

const a = new Account("Ada");
a.sessionId = "s-1";
console.log(a);

Wynik:

Account {
  owner: 'Ada',
  balance: 0,
  history: [],
  lastLogin: undefined,
  sessionId: 's-1'
}

Właściwości lastLogin i sessionId istnieją z wartością undefined, bo przy targecie ES2022 pola klas są prawdziwymi polami JavaScriptu. ! usuwa sprawdzenie, nie dodając żadnej ochrony w czasie wykonania, więc lepiej wybierać pozostałe formy. Ta flaga wymaga strictNullChecks: wyłączenie tamtej wyłącza też tę.

Włączanie strict w istniejącym projekcie

Przełączenie dużego projektu na strict naraz może dać setki błędów. Ponieważ strict jest domyślny w TypeScript 7, aktualizacja projektu, którego tsconfig.json nigdy nie wspominał o strict, sama go włącza. Napisz "strict": false, jeśli na czas migracji potrzebujesz starego zachowania. Droga, na której build cały czas przechodzi:

1. Dodaj "strict": true i wyłącz flagi z największą liczbą błędów, zwykle "strictNullChecks": false i "noImplicitAny": false.
2. Popraw pozostałe błędy, potem włącz kolejną flagę i powtórz.
3. Przy noImplicitAny większość poprawek to adnotacje parametrów. Przy strictNullChecks dodaj | undefined tam, gdzie wartości może brakować, a potem obsłuż to przez ?., ?? albo sprawdzenie if.
4. Tam, gdzie poprawka musi poczekać, dopisz w linii // @ts-expect-error z uzasadnieniem. W przeciwieństwie do @ts-ignore zgłasza on błąd, gdy problem zniknie, więc lista sama się skraca.

Nie wyciszaj błędów hurtowo przez as any albo !: każde takie użycie ukrywa dokładnie ten błąd, do którego wyłapywania dodano flagę.

Przydatne flagi spoza strict

Są osobno, bo odrzucają kod, który często jest poprawny. Wiele projektów i tak je włącza.

Najwięcej prawdziwych błędów wyłapuje noUncheckedIndexedAccess. Gdy jest włączona:

const scores = [90, 85];
const d: Record<string, number> = {};

const third: number = scores[2]; // error TS2322: Type 'number | undefined' is not assignable to type 'number'.
const c: number = d["x"];        // same error

const safe = scores[2] ?? 0;     // number
for (const s of scores) {        // for...of is not affected: s is number
    console.log(s);
}

tsc --init w TypeScript 7 włącza w generowanej konfiguracji noUncheckedIndexedAccess i exactOptionalPropertyTypes, obok strict.