TypeScript, který se škáluje dolů

Častý argument proti přísnému TypeScriptu na malých projektech zní, že ta ceremonie nestojí za to — je to přece „jen skript“ nebo „jen prototyp“, tak proč platit daň navíc. Přestal jsem s tím souhlasit. Přísnost se škáluje dolů stejně dobře jako nahoru — jen na každém konci dělá jinou práci.

Ve velké kódové bázi přísné typy brání jednomu týmu porušit předpoklady druhého. Ve skriptu o třech souborech dělají něco menšího, ale pořád cenného: brání tobě samotnému porušit vlastní předpoklady o šest týdnů později, kdy už jsi zapomněl, proč pole může být null.

Tady je konkrétní verze, na kterou jsem narazil. Malý interní nástroj na parsování CSV exportů měl funkci zhruba takhle:

function parseRow(row: string[]): { email: string; amount: number } {
  return {
    email: row[0],
    amount: Number(row[1]),
  };
}

S vypnutým strict se tohle zkompiluje. Se zapnutým noUncheckedIndexedAccess je row[0] typu string | undefined a kompilátor se ptá na otázku, kterou jsem si měl položit sám: co se stane u krátkého řádku? Poctivá odpověď byla, že aplikace spadne o dvě volání funkce později, se stack trace, který nikam smysluplně neukazuje. Oprava u zdroje — ověřit délku řádku, vracet typ podobný Result — zabrala deset minut a přesunula chybu tam, kde ji šlo skutečně vysvětlit.

Projekty, kde přísný režim vynechám, jsou přesně ty, ke kterým se pak vracím s lítostí. Ne proto, že by logika byla složitá, ale proto, že mi kód neříkal, co si smím dovolit předpokládat. Rychlý skript s volnými typy se rychle píše a pomalu se mu pak věří — a tím, kdo mu má věřit, bývám často já sám.

Můj výchozí nastavení teď: strict: true, noUncheckedIndexedAccess: true, všude, od prvního dne, včetně jednorázových skriptů. Když skript přežije první týden, jsem rád, že typy už tam jsou. Když nepřežije, ta minuta navíc na nastavení mě nic nestála.