{"dataset":{"id":"00000000-0000-0000-0000-000000000008","slug":"typescript-best-practices","name":"TypeScript best practices","description":"Source-linked guidance on TypeScript fundamentals: strict-mode compiler options, safer index access, type narrowing, the satisfies operator, and preferring unknown over any. Scoped to the TypeScript language and tsconfig; not a general JavaScript corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Prefer unknown over any, including catch variables","sourceUrl":"https://www.typescriptlang.org/tsconfig/useUnknownInCatchVariables.html","text":"The do's and don'ts page warns that using any disables type checking for the parts of your program that use it, and recommends unknown when you do not know what type you want to accept or when you want to accept anything because you will be blindly passing it through without interacting with it. Catch clauses are the canonical case: because JavaScript can throw any type of value, TypeScript historically typed catch clause variables as any; TypeScript 4.0 added support for changing the type of the variable in a catch clause from any to unknown with an explicit catch (err: unknown) annotation, and TypeScript 4.4 introduced the useUnknownInCatchVariables flag, which changes the default type of catch clause variables from any to unknown and is enabled under the strict family of options. With the flag on, err.message errors with \"'err' is of type 'unknown'\" until you narrow, for example with if (err instanceof Error), and the reference notes this pattern makes error handling more comprehensive because you cannot guarantee that the object being thrown is an Error subclass ahead of time. Scope: TypeScript 4.4 and later with useUnknownInCatchVariables. Reviewed October 4, 2026.","id":"typescript-best-practices:Prefer unknown over any, including catch variables","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"The satisfies operator","sourceUrl":"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html","text":"TypeScript 4.9 introduced the satisfies operator, which validates that the type of an expression matches some type without changing the resulting type of that expression. It resolves a common dilemma: you want to ensure an expression matches a type but also keep the most specific type of that expression for inference. Annotating a palette object as Record<Colors, string | RGB> catches a mistyped key like bleu, but each property then has the annotated union type, so palette.green.toUpperCase() errors because the property could be an RGB tuple; writing the object literal with satisfies Record<Colors, string | RGB> still catches the typo while toUpperCase() remains accessible. satisfies can also ensure that an object has all the keys of some type but no more — the release notes' favoriteColors example errors on an extra platypus key while retaining the per-property types — and can ensure that all of an object's property values conform to some type. Scope: TypeScript 4.9 and later. Reviewed October 4, 2026.","id":"typescript-best-practices:The satisfies operator","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Type narrowing and control flow analysis","sourceUrl":"https://www.typescriptlang.org/docs/handbook/2/narrowing.html","text":"Narrowing is the process of refining types to more specific types than declared, driven by control flow analysis: TypeScript uses reachability-based flow analysis to narrow types as it encounters type guards and assignments, and a variable can be observed to have a different type at each point as control flow splits off and re-merges. typeof narrows using the runtime strings \"string\", \"number\", \"bigint\", \"boolean\", \"symbol\", \"undefined\", \"object\", and \"function\"; truthiness narrowing works through conditionals, &&, ||, and Boolean negations; equality narrowing uses switch statements and equality checks like ===, !==, ==, and !=; the in operator narrows unions on whether an object or its prototype chain has a property of a given name; and instanceof checks whether the prototype chain of a value contains Foo.prototype. When existing JavaScript constructs are not enough, a user-defined type guard is a function whose return type is a type predicate such as pet is Fish. For structured data, discriminated unions give each member a shared field like kind with a distinct string literal type, so comparing kind narrows to one member; when narrowing removes every possibility TypeScript uses the never type, and because never is assignable to every type but nothing except never is assignable to never, assigning the leftover to never in a default case gives exhaustiveness checking in a switch. Scope: TypeScript handbook type narrowing. Reviewed October 4, 2026.","id":"typescript-best-practices:Type narrowing and control flow analysis","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"noUncheckedIndexedAccess for safer index access","sourceUrl":"https://www.typescriptlang.org/tsconfig/noUncheckedIndexedAccess.html","text":"TypeScript describes objects that have unknown keys but known values via index signatures, so an interface like EnvironmentVars with declared NAME and OS properties plus a [propName: string]: string index signature treats an undeclared access such as env.NODE_ENV as a plain string. Turning on noUncheckedIndexedAccess adds undefined to any undeclared field in the type, so env.NODE_ENV becomes string | undefined while the declared NAME and OS keep their exact string types. noUncheckedIndexedAccess is not part of the strict-mode family and must be opted into on its own — that scoping note is Koskamo editorial guidance, as is the recommendation to narrow away the undefined branch before using an indexed value. Scope: tsconfig compiler options. Reviewed October 4, 2026.","id":"typescript-best-practices:noUncheckedIndexedAccess for safer index access","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Strict mode with the tsconfig strict flag","sourceUrl":"https://www.typescriptlang.org/tsconfig/strict.html","text":"The strict flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness. Turning it on is equivalent to enabling all of the strict-mode family options, and you can then turn off individual strict-mode family checks as needed. Future versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program; when appropriate and possible, a corresponding flag is added to disable that behavior. The handbook's Strictness section calls out the two biggest flags in the family as noImplicitAny, which issues an error on variables whose type is implicitly inferred as any, and strictNullChecks, which makes handling null and undefined explicit instead of leaving them assignable to any other type; it also recommends that a new codebase always turn these strictness checks on. useUnknownInCatchVariables is likewise enabled under the strict family of options. Scope: tsconfig compiler options. Reviewed October 4, 2026.","id":"typescript-best-practices:Strict mode with the tsconfig strict flag","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}