TypeScript Recursive Types in 2026: Modeling JSON, Trees, and Deep Partial Without Hitting the Limit

A developer demonstrates how TypeScript recursive types can model deeply nested structures like JSON, trees, and deep partial objects without hitting the compiler's depth limit, preserving type safety at all levels. The approach uses a base case to terminate recursion and prevents runtime errors by catching path issues at compile time.

This article was written with the assistance of AI, under human supervision and review. Most TypeScript codebases handle nested data—JSON responses, file trees, comment threads—by writing any or falling back to runtime validation. The compiler cannot protect operations on deeply nested structures because the types stop at one or two levels. When a frontend engineer fetches a configuration object with arbitrary nesting and tries to access config.theme.colors.primary.default , the type system offers no help. The runtime throws Cannot read property 'default' of undefined and the developer spends an hour tracing the shape. Problem flow where nested data loses type safety Recursive types solve this by letting the type system follow structure to any depth. A JSONValue type that references itself models arrays of objects containing arrays—TypeScript infers the entire shape and catches path errors at compile time. The compiler sees that config.theme.colors might be undefined and forces the developer to handle it before accessing .primary . Solution flow where recursive types maintain type safety at all depths This distinction is critical. Without recursive types, teams write defensive runtime checks everywhere or accept silent failures. With recursive types, the compiler enforces safety once in the type definition and every consumer benefits automatically. null , unknown to terminate recursion and prevent infinite expansion during type checking.A recursive type is a type that references itself within its own definition, enabling the compiler to model structures that nest indefinitely. The classic example is a linked list node where each node points to another node of the same type. TypeScript resolves these definitions by deferring the expansion—when the compiler encounters a recursive reference, it treats the type as a placeholder until the structure terminates with a base case. Recursive type resolution showing base case termination The key insight is that recursion in types mirrors recursion in runtime code. A recursive function needs a termination condition to avoid infinite loops; a recursive type needs a base case—typically a primitive or union with non-recursive branches—to avoid infinite expansion. Without a base case, the compiler attempts to expand the type forever and eventually hits the depth limit. TypeScript's structural type system means recursive types work seamlessly with inference. When a function accepts a recursive type parameter, the compiler walks the structure and infers the exact shape. This matters because developers can write type-safe operations on nested data without annotating every level manually. The recursion depth limit exists as a safety valve. In TypeScript 5.6 and beyond, the compiler allows approximately 50 nested expansions before throwing an error. Most real-world data structures—even heavily nested JSON or deep file trees—stay well below this threshold. The limit only becomes a problem when a type definition creates an infinite expansion or when conditional types cause exponential branching during inference. JSON supports primitives, arrays, and objects that can nest arbitrarily. The standard approach in TypeScript is to type JSON as any , losing all safety. A recursive type models the exact JSON specification while preserving type information at every level. type JSONPrimitive = string | number | boolean | null; type JSONValue = | JSONPrimitive | JSONValue | { key: string : JSONValue }; // Usage: parsing API responses with full type safety function processConfig config: JSONValue : void { if typeof config === "object" && config == null && Array.isArray config { // TypeScript knows config is { key: string : JSONValue } const theme = config.theme; if typeof theme === "object" && theme == null && Array.isArray theme { const colors = theme.colors; // Compiler enforces checking at each level } } } // Example: type-safe path access with narrowing const apiResponse: JSONValue = { user: { profile: { name: "Alice", preferences: { theme: "dark", notifications: true } } } }; This definition covers every valid JSON structure. The base case— JSONPrimitive —terminates recursion for leaf values. The recursive branches— JSONValue and { key: string : JSONValue } —allow nesting to any depth. TypeScript infers the exact type when you assign a literal object, but the recursive definition ensures the compiler accepts any conforming structure. The practical benefit shows when developers access nested properties. Without recursive types, accessing apiResponse.user.profile.name compiles but provides no safety—any misspelling or missing property fails at runtime. With JSONValue , the compiler forces type narrowing at each level. You must check that user exists and is an object before accessing profile . This requirement seems verbose, but it catches bugs that would otherwise manifest as production errors. Teams building API clients or configuration parsers use this pattern extensively. The type definition goes in a shared types file, and every function that consumes API data references JSONValue . The initial cost is a single recursive type; the payoff is eliminating an entire class of runtime failures across the codebase. Tree structures—DOM nodes, file systems, organizational charts—require recursive types to model parent-child relationships accurately. A file system node can be a file leaf or a directory containing more nodes branch . This maps directly to a recursive union type. type FileSystemNode = File | Directory; interface File { type: "file"; name: string; size: number; content: string; } interface Directory { type: "directory"; name: string; children: FileSystemNode ; } // Type-safe tree traversal function calculateSize node: FileSystemNode : number { if node.type === "file" { return node.size; } // TypeScript knows node is Directory here return node.children.reduce sum, child = sum + calculateSize child , 0 ; } // Example: modeling a project structure const projectTree: Directory = { type: "directory", name: "src", children: { type: "file", name: "index.ts", size: 1024, content: "export from './app';" }, { type: "directory", name: "components", children: { type: "file", name: "Button.tsx", size: 2048, content: "export const Button = = <button / ;" } } }; // Type-safe search with exhaustive checking function findFile node: FileSystemNode, targetName: string : File | null { if node.type === "file" { return node.name === targetName ? node : null; } for const child of node.children { const result = findFile child, targetName ; if result return result; } return null; } The discriminated union— type: "file" | "directory" —lets TypeScript narrow the type in conditional branches. When the compiler sees node.type === "file" , it knows node must be a File and provides accurate autocomplete for size and content . This pattern eliminates the need for runtime type guards or casting. The recursion happens in the children array of Directory . Each child is a FileSystemNode , which can itself be a Directory with more children. TypeScript resolves this by treating FileSystemNode as a deferred type reference until the actual structure is known. When you assign a literal tree, the compiler infers the full shape and validates every nested node matches the type definition. This approach scales to complex trees with dozens of levels. The type definition remains concise—three interfaces and one union—but the compiler enforces correctness at every depth. Operations like search, traversal, and transformation gain full type safety without additional annotations. For teams managing hierarchical data, this pattern is non-negotiable. The alternative—untyped objects with runtime checks—creates maintenance burden and hides structural errors until production. Recursive types front-load the cost into type definitions and eliminate runtime surprises. Utility types like Partial<T make all properties optional, but only at the top level. For nested objects, developers need DeepPartial<T to make every property at every depth optional. This requires a recursive type that descends through object structures. type DeepPartial<T = T extends object ? T extends Array<infer U ? Array<DeepPartial<U : T extends ReadonlyArray<infer U ? ReadonlyArray<DeepPartial<U : { K in keyof T ?: DeepPartial<T K } : T; // Example: configuration with nested defaults interface AppConfig { server: { host: string; port: number; ssl: { enabled: boolean; certPath: string; }; }; database: { host: string; credentials: { username: string; password: string; }; }; } // Merge partial config with defaults function mergeConfig defaults: AppConfig, overrides: DeepPartial<AppConfig : AppConfig { // Type-safe deep merge logic return { server: { host: overrides.server?.host ?? defaults.server.host, port: overrides.server?.port ?? defaults.server.port, ssl: { enabled: overrides.server?.ssl?.enabled ?? defaults.server.ssl.enabled, certPath: overrides.server?.ssl?.certPath ?? defaults.server.ssl.certPath } }, database: { host: overrides.database?.host ?? defaults.database.host, credentials: { username: overrides.database?.credentials?.username ?? defaults.database.credentials.username, password: overrides.database?.credentials?.password ?? defaults.database.credentials.password } } }; } // Usage: partial overrides with full type safety const customConfig = mergeConfig defaultConfig, { server: { ssl: { enabled: true } } } ; The conditional logic handles arrays separately because Array<T has its own prototype methods that should not become optional. The recursive case— { K in keyof T ?: DeepPartial<T K } —maps over every key and marks it optional while recursing into the property type. This pattern composes with other type operations like Readonly or Required . The implication here is that recursive utility types scale complexity linearly. A non-recursive solution requires developers to write Partial at every nesting level manually, which breaks when the structure changes. A recursive type handles arbitrary depth automatically and adjusts when the underlying interface evolves. Production codebases use DeepPartial for configuration merging, API request builders, and form state management. The type definition is reusable across projects, and the compiler enforces correctness without runtime overhead. Once the recursive type exists, every function that needs partial updates gains type safety for free. Other useful recursive utilities include DeepReadonly<T for immutability and DeepRequired<T for exhaustive validation. The pattern is identical—conditional recursion with array handling—but the mapped type operation changes readonly or -? . These utilities demonstrate how recursive types amplify TypeScript's existing features rather than replacing them. The recursion depth limit triggers when TypeScript expands a type more than approximately 50 times during inference. Practical recursive types rarely hit this ceiling unless the definition creates infinite expansion or exponential branching during evaluation. Flow showing recursion depth management strategies The most common failure mode is a recursive type without a proper base case. If DeepPartial<T does not check whether T is an object before recursing, the compiler attempts to apply DeepPartial to primitives infinitely. The fix is explicit termination: T extends object ? ... : T . This pattern ensures recursion stops at primitives. Another pitfall is conditional types that create exponential branching. Consider a type that recurses into both object keys and array elements simultaneously—each level doubles the number of type branches the compiler must evaluate. After a few levels, the expansion exceeds the depth limit even though the actual data structure is shallow. The solution is to flatten conditionals using distributive properties or split recursive cases into separate helper types. Tail-recursive patterns help by structuring types so the recursive call is the final operation. This does not eliminate depth counting in TypeScript's type system unlike runtime tail call optimization , but it reduces intermediate type allocations and makes inference faster. For example, a Flatten<T type that accumulates results in a tuple parameter can avoid re-evaluating the entire chain at each level. // Bad: non-tail-recursive with intermediate allocations type DeepFlattenBad<T = T extends Array<infer U ? DeepFlattenBad<U : T extends object ? { K in keyof T : DeepFlattenBad<T K } : T; // Better: tail-recursive accumulation conceptual, not always applicable type DeepFlattenGood<T, Acc extends unknown = = T extends Array<infer U ? DeepFlattenGood<U, ...Acc, U : T; // Practical: limit recursion with a depth counter type DeepPartialSafe<T, Depth extends number = 10 = Depth extends 0 ? T : T extends object ? T extends Array<infer U ? Array<DeepPartialSafe<U, Prev<Depth : { K in keyof T ?: DeepPartialSafe<T K , Prev<Depth } : T; type Prev<N extends number = N extends 10 ? 9 : N extends 9 ? 8 : N extends 8 ? 7 : N extends 7 ? 6 : N extends 6 ? 5 : N extends 5 ? 4 : N extends 4 ? 3 : N extends 3 ? 2 : N extends 2 ? 1 : 0; The depth-limited pattern gives recursive types an explicit cutoff. After 10 levels, the type stops recursing and returns T as-is. This prevents depth limit errors while still covering the vast majority of real-world structures. Most production data does not nest beyond five or six levels, so a limit of 10 provides a comfortable margin. Teams encounter depth limit errors most often when composing multiple recursive types— DeepPartial<DeepReadonly<T —or when using recursive types in generic constraints. The fix is to flatten composition or inline the logic. If DeepReadonly already handles arrays correctly, there is no need for DeepPartial to do it separately. Combining concerns into a single recursive type reduces the number of expansions the compiler must perform. In practice, depth limit errors are rare when recursive types follow these rules: explicit base cases, single-responsibility recursion one concept per type , and composition through union rather than nesting. When an error does occur, the fix is usually structural—adding a termination condition or splitting a complex type into simpler helpers—not a compiler limitation. Recursive types, tuple spreading, and conditional types overlap in capability but serve different purposes in TypeScript's type system. Understanding when each approach excels prevents overengineering and keeps types maintainable. Comparison flowchart showing when to use each type pattern Recursive types model structures that reference themselves—trees, graphs, nested objects. They work by deferring expansion until the structure terminates with a base case. This makes them ideal for data that has arbitrary depth but predictable shape. The type definition is concise and the compiler handles inference automatically. Tuple spreading manipulates fixed-length arrays at the type level. Operations like prepending an element, reversing order, or flattening nested tuples use the spread operator ... in type expressions. Tuple spreading shines for function signatures with variadic parameters or when building type-safe wrappers around Promise.all . It does not handle self-referencing structures well because tuples have a known length—recursion on tuples often creates infinite expansion unless carefully bounded. Conditional types provide branching logic— T extends U ? X : Y —allowing types to change behavior based on structure. They power discriminated unions, type narrowing, and constraint-based overloads. Conditional types often compose with recursion as in DeepPartial but are not inherently recursive. A conditional type checks a condition once per invocation; a recursive type invokes itself repeatedly. The key difference is intent. Recursive types model nested data. Tuple spreading rearranges finite sequences. Conditional types implement logic gates. Using a recursive type to rearrange function parameters is overkill and likely causes depth limit errors. Using tuple spreading to model a tree structure fails because tuples cannot represent arbitrary nesting. Using conditionals without recursion works for shallow transformations but breaks down for deep structures. In production, teams use recursive types for domain models—configuration, API responses, file systems. They use tuple spreading for utility functions that wrap variadic APIs. They use conditional types for generic constraints and type guards. Mixing these patterns appropriately keeps type definitions readable and compile times fast. When an engineer reaches for a recursive type, the first question should be: does this data reference itself? If yes, recursion is correct. If no, a simpler approach—mapped types, unions, or conditionals—likely suffices. This discipline prevents type definitions from becoming unreadable and unmaintainable. TypeScript 5.6 uses a depth limit of approximately 50 recursive expansions during type inference. This number is not a hard-coded constant but emerges from internal heuristics that detect infinite loops. Most real-world recursive types stay well below this threshold because they terminate at base cases within a few levels. Recursive types have zero runtime cost—they exist only during compilation and disappear from emitted JavaScript. Complex recursive types can slow down the TypeScript compiler during type checking, but this affects developer experience longer tsc runs rather than application performance. Well-structured recursive types with explicit base cases compile quickly even in large codebases. This error means the compiler expanded a recursive type more than the depth limit without reaching a base case. Check that the type has an explicit termination condition T extends object ? ... : T and that conditionals do not create exponential branching. Adding a depth counter parameter as shown in the "Avoiding the Recursion Depth Limit" section forces early termination and reveals where the expansion diverges. Use recursive types when the data genuinely nests arbitrarily—JSON, trees, comment threads. For structures with a known, shallow nesting depth like most database models with one or two levels of relations , explicit interface definitions are clearer and faster to compile. Recursive types add value when depth varies or when you need a single type to handle all nesting levels. Recursive types compose perfectly with discriminated unions. A FileSystemNode type that is a union of File | Directory allows type narrowing on the discriminant node.type === "file" , and TypeScript narrows recursively through the structure. This pattern is standard in production codebases for modeling polymorphic trees and graphs. Recursive types transform how teams model nested data in TypeScript. The upfront cost is learning the pattern—base cases, self-reference, termination conditions—but the payoff is eliminating an entire class of runtime failures. When a recursive type models JSON or a file tree, every function that consumes that data gains type safety automatically. The compiler enforces correctness at every depth without additional runtime checks. The practical advice is straightforward. Use recursive types for data that references itself—trees, graphs, nested objects. Add explicit base cases to prevent infinite expansion. Limit depth with a counter when composing multiple recursive types. Prefer discriminated unions for polymorphic structures to enable type narrowing. Avoid recursion for fixed-depth data where explicit interfaces are clearer. Teams that adopt recursive types report fewer production bugs related to missing or malformed nested properties. The compiler catches path errors at compile time instead of letting them fail at runtime. Configuration systems become type-safe without sacrificing flexibility. API clients gain complete type information for deeply nested responses. The code is more maintainable because the type definition documents the structure once and the compiler enforces it everywhere. That covers the essential patterns for recursive types in TypeScript. Apply these in production and the difference will be immediate. The compiler will catch structural errors before they reach users, and your codebase will handle nested data with confidence.