Page 12 - TypeScript

A single Zod schema is quick to write, but in a growing codebase with dozens of endpoints and domain objects, a lack of deliberate architecture quickly leads to duplicated validation code sprawling everywhere. This article shows concrete Zod schema design patterns for reuse, discriminated unions, recursive tree types, transform pipelines and branded types, so validation logic gets the same structure as any other part of the application architecture.

SolidJS skips the virtual DOM entirely and instead updates individual DOM nodes directly through a fine-grained signal system. TypeScript accompanies this model with precise types for signal access, component props and typed control flow components.

The built in Error class from JavaScript is rarely enough for a growing codebase: it carries no error codes, no structured metadata, and no clean serialization. A well thought out error class hierarchy solves these problems with a shared base class, consistent instanceof checks, and cause chaining for connected failure causes.

esbuild, SWC, and Babel compile each file on its own, without type information from other files. isolatedModules flags exactly the cases that would break under that constraint.

Introduced in TypeScript 4.9, the satisfies operator closes a gap between explicit type annotations and as type assertions. It checks whether an expression matches a type while preserving the expression's own, narrower type.

Custom type predicates let you tell the TypeScript compiler, through a function you write yourself, exactly what concrete type a value has after a check. Used correctly, they replace manual type assertions with real narrowing logic the compiler can actually follow.

Anyone who treats TypeScript as just PHP with types quickly trips over structural type checking, reference semantics for objects, and the absence of nominal typing. This article explains the fundamental difference between primitive and object types, contrasts TypeScript's duck typing philosophy directly with PHP, and surfaces the most common misconceptions developers bring along when switching.

A type change that turns consumer code into a compile error is a breaking change, even without any change to runtime behavior at all. Backwards compatibility for type changes means deliberately using overloads, deprecation comments, API reports and Semantic Versioning so a TypeScript library can grow without surprising existing consumers on every release.

A TypeScript type that compiles without errors is not automatically correct. Complex generic and conditional types can silently widen to any, accept an invalid shape they should reject, or narrow incorrectly inside a conditional branch. Tools like tsd, expect-type, and Vitest's expectTypeOf make exactly this behavior testable, purely at compile time, without a single runtime test.

Large TypeScript projects often suffer from slow builds because the compiler fully rechecks every file and recomputes every type on each run. This article shows in practice how the tsbuildinfo cache, the incremental and composite flags, and project references combined with tsc build noticeably reduce compile times in monorepos and large codebases, including concrete diagnosis and measurement methods for stubborn bottlenecks in everyday work.