The Boundaries of TypeScript's Type System: When Advanced Types Are Worth Using

Once a TypeScript project reaches a certain scale, the team usually has to answer an architectural question: Which business constraints should the type system enforce?

One approach treats TypeScript as “JavaScript with type annotations” and adds declarations only for parameters, return values, and data structures.

Another approach gives route parsing, state combinations, string grammars, numeric calculations, and even business rules to the type system. Conditional types, template literal types, recursive types, and union calculations then derive more precise results at compile time.

The first approach is easy to understand but may miss the value of inference. The second is expressive, but it can slow type checking, make errors difficult to understand, and drive maintenance costs up quickly.

The central question in advanced TypeScript is therefore never simply: Can this type be written?

The real question is: Does this constraint belong in the type system, and do its benefits outweigh the costs of understanding, diagnostics, compilation, and future evolution?

This is an architectural decision first and a type-level programming technique second—the practice often called “type gymnastics.”

1. First establish what TypeScript can and cannot do

Before studying advanced types, return to TypeScript's design goals. Its official design principles emphasize:

• statically identifying likely errors;

• providing a structured development mechanism for large codebases;

• adding no runtime overhead to generated code;

• preserving JavaScript's runtime behavior;

• using an erasable structural type systemA structural type system determines compatibility from the members a type actually contains, rather than requiring two types to explicitly declare inheritance or implementation. Types from different sources are assignable when their structures satisfy the same requirements.;

• balancing correctness with developer productivity;

• not pursuing a fully sound type system that can prove correctness.

TypeScript is therefore neither a proof system nor a runtime contract system.

Because of type erasureTypeScript's type information participates only in compile-time checking and is removed when JavaScript is emitted. Interfaces, type aliases, and generics therefore cannot validate external data at runtime., type aliases, interfaces, generic parameters, and other type information disappear when JavaScript is emitted:

type UserId = string & { readonly __brand: "UserId" }; function loadUser(id: UserId) {  return fetch(`/users/${id}`);}

After compilation, UserId does not exist. At runtime, the value is still an ordinary string.

This gives us the first boundary:

TypeScript can check whether code in the current compilation context has consistent type relationships, but it cannot prove that runtime input is genuine, trustworthy, or consistent with its declaration.

The type system mainly helps developers preserve relationships inside the code. It cannot guarantee that data from a network, disk, database, user, or third-party service is genuine, complete, and correctly declared.

2. When does the type system begin to compute?

The simplest TypeScript only describes existing values:

interface User {  id: string;  name: string;} function getUser(id: string): Promise<User> {  // ...}

These types are static descriptions of data structures.

Once a return type depends on an input type, however, the type system is no longer merely describing data. It is calculating a result:

type AwaitedReturn<F> = F extends (...args: any[]) => Promise<infer Result>  ? Result  : never; async function loadUser() {  return {    id: "user-1",    name: "Ada",  };} type User = AwaitedReturn<typeof loadUser>;

AwaitedReturn accepts a type, pattern-matches it to extract information, and produces a new type.

At this point, the type layer behaves like a small programming language:

Advanced types are therefore not a collection of unrelated, unusual syntax. They are a set of type-level programming capabilities.

The problem is that once the type layer computes, it also creates algorithmic complexity, leaks implementation details, incurs debugging costs, and accumulates technical debt.

3. A complexity scale for advanced types

Not all advanced types carry the same risk. In engineering practice, they can be divided into five levels:

3.1 L0: static description

interface Order {  id: string;  status: "pending" | "paid" | "cancelled";}

Types like this describe a domain model directly and are usually low-risk and high-value.

3.2 L1: expressing relationships between types

function getProperty<ObjectType, Key extends keyof ObjectType>(  object: ObjectType,  key: Key,): ObjectType[Key] {  return object[key];}

The generic is not here merely to “support any type.” It establishes a relationship among three positions:

• object determines ObjectType;

• key must be a key of ObjectType;

• ObjectType[Key] determines the return value.

The greatest value of a generic is not abstracting a type; it is preserving a relationship.

3.3 L2: generating new types

type Handlers<T> = {  [Key in keyof T as `on${Capitalize<Key & string>}`]: (value: T[Key]) => void;};

This kind of type can eliminate repeated declarations and is especially useful in configuration systems, event systems, and public libraries.

3.4 L3: implementing a type-level algorithm

type Leaf =  string | number | boolean | bigint | symbol | null | undefined | Date; // A simplified example for ordinary objectstype Paths<T> = T extends Leaf  ? never  : {      [Key in keyof T & string]: T[Key] extends Leaf        ? Key        : Key | `${Key}.${Paths<T[Key]> & string}`;    }[keyof T & string];

This is no longer just a property transformation. It recursively traverses a data structure.

3.5 L4: type-level metaprogramming

Examples include:

• all permutations of a union;

• addition, subtraction, multiplication, and division simulated with tuples;

• a type-level JSON parser;

• a complete domain model generated from a string grammar;

• large Cartesian products of union types.

This code can be technically fascinating. Unless it lives inside a public library and delivers clear benefits to many callers, however, it can easily become a maintenance burden.

4. Six common type-programming patterns

Complex types appear to vary greatly, but most are built from six recurring patterns.

4.1 Pattern matching: extracting existing information

TypeScript uses conditional typesA type expression that chooses a result branch from a type relationship, in the form T extends U? X: Y. It is commonly used to filter, extract, and transform types. and the [infer keyword]{term="infer-keyword"} to pattern-match types:

type FunctionResult<F> = F extends (...args: any[]) => infer Result  ? Result  : never;

In essence, this type:

1. checks whether the input matches a structure;

2. binds one part of that structure to a temporary type variable;

3. uses the variable in the remaining computation.

Utility types such as Parameters, ReturnType, and Awaited are all based on this pattern.

Pattern matching is best when the information already exists and only needs to be extracted.

4.2 Reconstruction: generating a new type from an old one

A type parameter cannot be reassigned like a JavaScript variable. A type transformation usually creates a new type:

type Mutable<T> = {  -readonly [Key in keyof T]: T[Key];}; type Optional<T> = {  [Key in keyof T]?: T[Key];};

The as clause in a mapped typeA mechanism that iterates over the keys of an existing type to produce a new object type, changing property types, optionality, readonly status, or key names in bulk. can also rename keys:

type GetterMethods<T> = {  [Key in keyof T as `get${Capitalize<Key & string>}`]: () => T[Key];};

This pattern suits:

• API DTO mapping;

• form-state generation;

• event-handler generation;

• ORM result mapping;

• permission-model derivation.

But take care: if the transformed type is harder to explain than the original, an explicit declaration may cost less to maintain.

4.3 Recursion: handling an unknown number of levels or items

When the length, depth, or number of levels is not known in advance, the type system usually needs recursion:

type DeepReadonly<T> = T extends (...args: any[]) => any  ? T  : T extends object    ? {        readonly [Key in keyof T]: DeepReadonly<T[Key]>;      }    : T;

Recursive types commonly appear in:

• deep object transformations;

• path generation;

• tuple traversal;

• string parsing;

• nested Promise unwrapping.

Recursion is also where complexity begins to grow quickly. Every added branch, union, or nested mapping can significantly increase the number of type instantiations.

4.4 Tuple counting: simulating type-level numeric operations

TypeScript has no general type-level arithmetic operators. Type exercises often calculate with tuple lengths:

type BuildTuple<  Length extends number,  Result extends unknown[] = [],> = Result["length"] extends Length  ? Result  : BuildTuple<Length, [...Result, unknown]>; type Add<A extends number, B extends number> = [  ...BuildTuple<A>,  ...BuildTuple<B>,]["length"];

This demonstrates the expressive power of TypeScript's type system, but its engineering value is limited.

If a business design truly requires substantial numeric computation at the type level, question the model before questioning the type syntax.

More mature approaches usually:

• declare the result explicitly;

• use code generation;

• generate declaration files in a runtime build step;

• move complex computation back into an ordinary program.

The type system is suitable for expressing constraints, not for replacing a general-purpose computation engine.

4.5 Conditional-type distribution: processing many possibilities at once

When a type parameter appears directly on the left side of a conditional type, distributive conditional typesWhen a conditional type directly checks a generic parameter and that parameter receives a union, TypeScript evaluates each union member separately and combines the results into another union. process each union member separately:

type RemoveNullish<T> = T extends null | undefined ? never : T; type Result = RemoveNullish<string | null | number | undefined>;// string | number

This feature is powerful because it lets a union behave like a set that can be mapped or filtered.

It is also a common source of rapidly increasing type counts, often called a “type explosion.” If a type distributes over several large unions and then combines them through template literals, the result can approach a Cartesian product.

For example:

type Locale = "en" | "zh" | "ja" | "fr";type Resource = "user" | "order" | "product" | "payment";type Action = "create" | "read" | "update" | "delete"; type Permission = `${Locale}:${Resource}:${Action}`;

Here, 4 × 4 × 4 produces only 64 members, which is manageable. If each dimension has dozens of members and is combined with recursion and conditional types, the compiler must maintain and compare many intermediate types.

4.6 Special type behavior: any, never, unknown, and variance

Advanced types require more than syntactic intuition. You must also understand the semantics of special types.

4.6.1 unknown

unknown means “a value exists, but its type is unknown.”

It can receive any value but must be narrowed before use, making it a safe representation for unknown input.

4.6.2 any

any bypasses local type checking. It is not merely a broad type; it can spread into later inference.

Once a public API returns any, callers may lose type safety across an entire expression chain without noticing.

4.6.3 never

never represents a value that cannot exist. It can describe an unreachable branch or filter members out of a union.

4.6.4 Covariance and contravariance

Parameter and return positions have different directions of compatibility. VarianceThe way compatibility between generic types changes with the relationship between their type arguments. Common forms include covariance, contravariance, invariance, and bivariance; function parameter and return positions follow particularly different rules. describes this relationship:

interface Animal {  name: string;} interface Dog extends Animal {  bark(): void;} type Consumer<T> = (value: T) => void; declare let consumeAnimal: Consumer<Animal>;declare let consumeDog: Consumer<Dog>; consumeDog = consumeAnimal; // The reverse direction is unsafe:// consumeAnimal = consumeDog;

A function that can handle every Animal can naturally handle a Dog; a function that only handles Dog cannot safely receive every possible Animal.

These rules directly affect:

• callback design;

• event-handler compatibility;

• union-to-intersection transformations;

• generic constraints;

• function overloads;

• the evolution of public-library APIs.

TypeScript also preserves some non-strict behavior for compatibility with the JavaScript ecosystem. Architecture must not assume that it is a completely sound formal type system.

5. When advanced types are worth the investment

The greatest value of advanced types is not saving a few lines of declarations. It is expressing stable type relationships.

5.1 Make invalid states difficult to represent

Consider a domain-event system:

type DomainEvent =  | {      type: "user.created";      payload: {        id: string;        email: string;      };    }  | {      type: "user.deleted";      payload: {        id: string;        reason?: string;      };    }; type HandlerMap<Event extends { type: PropertyKey }> = {  [Type in Event["type"]]: (    event: Extract<Event, { type: Type }>,  ) => void | Promise<void>;};

The generated handler type automatically connects each event name to its payload:

type DomainEventHandlers = HandlerMap<DomainEvent>;

The result is equivalent to:

type DomainEventHandlers = {  "user.created": (event: {    type: "user.created";    payload: {      id: string;      email: string;    };  }) => void | Promise<void>;   "user.deleted": (event: {    type: "user.deleted";    payload: {      id: string;      reason?: string;    };  }) => void | Promise<void>;};

The value is not merely “less code.” Instead:

• event names and payloads cannot be mismatched;

• adding an event can trigger a completeness check for handlers;

• renaming an event produces complete refactoring feedback;

• the editor can offer precise completion based on the event name.

This is a worthwhile type investment.

5.2 Encapsulate complexity inside a public API

Advanced types have an important economic model:

A few maintainers carry the implementation complexity, while many callers share the benefit.

If one business module uses a complex type once, its maintenance return is usually low.

If the type lives in a framework, SDK, component library, or infrastructure package and provides precise inference at hundreds or thousands of call sites, the complex implementation may be justified.

A rough model is:

Return on type investment=error-prevention benefit+ completion benefit+ refactoring benefit+ reuse benefit from the number of callers- implementation comprehension cost- compilation cost- error-diagnosis cost- version-migration cost

A public library may be internally complex, with one condition:

The API seen by callers must be simpler than its implementation.

If a caller must understand conditional-type distribution, contravariance, recursive termination, and five layers of generics to use the API, the complexity has not been encapsulated. It has merely been transferred.

6. Six areas most likely to cause trouble

6.1 Mistaking compile-time checking for runtime validation

The following code does not validate an HTTP response:

interface User {  id: string;  name: string;} const user = (await response.json()) as User;

as User only asks the compiler to trust the developer.

If the server returns:

{  "id": 123,  "display_name": "Ada"}

TypeScript will not stop the invalid data from entering the system at runtime.

The correct boundary is:

flowchart TD
    A["External data<br/>HTTP responses, message queues, databases, files"] --> B["Runtime parsing and validation"]
    B --> C["Validated domain objects"]
    C --> D["Static TypeScript relationships"]
    D --> E["Business logic and API inference"]

External data must first pass through a runtime schema, parser, or validator. After validation, TypeScript can preserve and propagate relationships within the code.

6.2 Using any to conceal a failed type design

any often appears as a fallback branch in a complex type:

type Result<T> = T extends SomeKnownShape ? Compute<T> : any;

Unsupported input then silently becomes untyped.

Better choices may include:

• never: reject unsupported input explicitly;

• unknown: require the caller to narrow it;

• a structured error type: show the caller why computation failed;

• the original type T: preserve information when no transformation is possible;

• a simpler API: decline to support excessively broad input.

any should not be the default escape hatch when a complex type cannot produce a safe result.

6.3 Recursion and unions causing combinatorial explosion

A recursive conditional type instantiated with a union is instantiated separately for each member.

If recursion creates more unions, complexity can grow exponentially.

Common symptoms include:

• editor suggestions become noticeably slow;

• hover information takes a long time to appear;

• “Type instantiation is excessively deep” errors occur;

• declaration files contain enormous anonymous types;

• tsc memory use and checking time rise abnormally;

• a small business change causes a large amount of type recomputation.

Making the type syntax shorter rarely helps at this point. The computation boundary needs to be redesigned.

6.4 Error messages lose domain meaning

If a user passes the wrong argument and receives dozens of lines of expanded conditional types, the API may be “type-safe” but still offer poor developer experience.

A good API should keep errors close to domain language:

Missing userId

This is more useful than:

Type '{ orgId: string; }' is not assignable toRouteParams<ExtractSegments<NormalizePath<...>>>

The type system should not merely reject an error; it should help a developer understand it.

6.5 Public declaration files become a compatibility burden

For a public library, types are API.

Even when runtime behavior is unchanged, modifying any of the following may break callers:

• generic parameter order;

• branches in a conditional type;

• inference priority;

• overload declaration order;

• readonly modifiers;

• union members;

• default generic parameters;

• distributive versus non-distributive behavior.

Public libraries therefore need dedicated tests for type behavior, not only runtime tests.

At a minimum, cover:

• inference results for valid input;

• rejection of invalid input;

• preservation of literals;

• reasonable fallback for dynamic values;

• compatibility with readonly input;

• declaration compatibility across TypeScript versions.

6.6 Creating a larger implicit relationship to remove repetition

Not all duplication should be eliminated. An explicit declaration such as:

interface CreateUserInput {  email: string;  name: string;}

may be easier to maintain than deriving it through several layers from a database model, form definition, API schema, and permission configuration.

Several concepts having the same structure today does not mean they belong to one model. For example:

• UserRecord in the database;

• UserResponse returned by the API;

• UserViewModel displayed by a page;

• UpdateUserInput submitted by a form.

They may share properties, but they evolve for different reasons and sit behind different security boundaries. Reusing one base type too aggressively can create incorrect coupling.

7. Compiler performance for complex types is a real engineering concern

TypeScript's official performance guide recommends:

• preferring interface extends to large intersections when combining object types;

• adding explicit annotations at performance hotspots, especially exported return types;

• using base types or inheritance hierarchies instead of enormous unions;

• naming complex conditional types so the compiler can cache their results;

• using Project References to divide large projects;

• locating problems with diagnostics and traces instead of optimizing by intuition.

7.1 Why large unions slow type checking

To determine whether a value is compatible with a union, the compiler may need to compare it against every member.

When union members must be deduplicated or compared with one another, some work approaches pairwise comparison. As the member count grows, the cost can rise quadratically.

Therefore, instead of declaring:

type HtmlElement =  | DivElement  | ImageElement  | InputElement  | ButtonElement  | /* dozens of members */ never;

extract a base interface when possible:

interface HtmlElement {  tagName: string;  attributes: Record<string, string>;} interface DivElement extends HtmlElement {  tagName: "div";}

This does not mean union types are bad. It means a large union should not simulate an inheritance or shared structure that already exists.

7.2 Why complex types should be named

When the following conditional type is inlined in a public method, it may be recomputed whenever related types are compared:

interface Processor<T> {  process<U>(    input: U,  ): U extends TypeA<T>    ? ResultA<U, T>    : U extends TypeB<T>      ? ResultB<U, T>      : ResultC<U, T>;}

Extracting it improves readability and makes a cacheable result easier for the compiler to reuse:

type ProcessResult<U, T> =  U extends TypeA<T>    ? ResultA<U, T>    : U extends TypeB<T>      ? ResultB<U, T>      : ResultC<U, T>; interface Processor<T> {  process<U>(input: U): ProcessResult<U, T>;}

7.3 How to measure performance

Common diagnostic commands include:

tsc --extendedDiagnostics -p tsconfig.json

This helps you inspect:

• file count;

• type count;

• type-instantiation count;

• memory use;

• Parse, Bind, Check, and Emit time.

For deeper analysis, generate a trace:

tsc -p tsconfig.json --generateTrace trace-output

Then use TypeScript's trace-analysis tooling to locate hotspots.

For a large project, continuously monitor:

• CI type-checking time;

• editor completion latency;

• TSServer memory use;

• .d.ts file size;

• incremental build time;

• the number of projects affected by one change.

7.4 Project References should not be overused

Project ReferencesTypeScript's mechanism for dividing a large codebase into independently compiled projects that reference one another. Combined with incremental builds, it can improve build performance and make compilation boundaries align explicitly with architecture. can divide a large codebase into independent compilation units, improving build time and architectural boundaries.

Project division has costs too:

• shared dependencies may be checked repeatedly by several projects;

• projects must emit and consume declaration files;

• the editor must manage a dependency graph;

• excessive splitting increases scheduling and configuration overhead.

The official performance guidance is to keep project counts within a reasonable range in a multi-project workspace rather than creating a project for every directory.

Project boundaries should align with real architectural boundaries, such as:

• a web client;

• a server;

• shared contracts;

• domain packages;

• test projects;

• independently released monorepo packages.

7.5 What TypeScript 7.0's native implementation means

As of 2026, the TypeScript team is porting the existing implementation to Go as the foundation for TypeScript 7.0 and provides a native preview. The team reports speedups approaching tenfold in some scenarios.

This will substantially lower type-checking costs in large projects, but it does not justify overdesigned types.

A faster compiler mainly reduces fixed overhead. It does not eliminate:

• exponentially growing union combinations;

• incomprehensible error messages;

• public-type compatibility obligations;

• overly deep recursive models;

• the team's cognitive burden.

A faster compiler does not make difficult types easier to read.

8. Dividing responsibility between type programming and runtime validation

An architecture can use the following division:

For static configuration, the [satisfies operator]{term="satisfies-operator"} is an excellent boundary tool:

type RouteDefinition = {  path: `/${string}`;  auth: "public" | "required";}; const routes = {  userDetail: {    path: "/users/:id",    auth: "required",  },  health: {    path: "/health",    auth: "public",  },} as const satisfies Record<string, RouteDefinition>;

It preserves all of the following at once:

• the object's specific key names;

• the string literal in path;

• the literal in auth;

• a constraint check over the complete structure.

That is more useful for later inference than annotating the variable directly as Record<string, RouteDefinition>.

For wrapper functions, const type parameters introduced in TypeScript 5.0 can also make an API preserve more literal information by default. Their purpose is still to improve inference, not to validate runtime data.

9. Case study: a reasonable design or overengineering?

Suppose we want to derive parameter names from a route string:

type ParamNames<Path extends string> =  Path extends `${string}:${infer Param}/${infer Rest}`    ? Param | ParamNames<`/${Rest}`>    : Path extends `${string}:${infer Param}`      ? Param      : never; type RouteParams<Path extends string> = {  [Key in ParamNames<Path>]: string;}; declare function navigate<const Path extends string>(  path: Path,  params: RouteParams<Path>,): void;

At the call site:

navigate("/orgs/:orgId/users/:userId", {  orgId: "org-1",  userId: "user-1",});

Whether this design is worthwhile depends on its environment:

As the signals in the right column accumulate, the value of extending the string-parsing type declines quickly. Rather than make the type system duplicate an evolving route grammar, use more direct modeling.

An explicit configuration may be more reliable:

const routes = {  userDetail: {    path: "/orgs/:orgId/users/:userId",    params: {      orgId: "string",      userId: "string",    },    auth: "required",  },} as const satisfies Record<  string,  {    path: `/${string}`;    params: Record<string, "string" | "number">;    auth: "public" | "required";  }>;

This configuration contains a little repetition, but it integrates more easily with runtime validation, documentation and client generation, multilingual systems, debugging, and evolving route syntax. The duplication buys an explicit data boundary and a more direct maintenance path.

Good architecture does not eliminate all repetition. It distinguishes dangerous duplication that is likely to drift from reasonable duplication that expresses separate responsibilities and boundaries.

10. Evaluating whether a complex type is worth introducing

Before adding an L3 or L4 type, review it with six questions:

1. Does the constraint truly exist at compile time? If the required information exists only at runtime, type computation should not be the primary mechanism.

2. Is there a stable relationship between input and output? Generics are good at expressing stable relationships. If callers choose the entire return type and it cannot be checked from the input, the generic is usually a hidden type assertion.

3. Who bears the complexity, and who benefits? One maintainer carrying complexity for a thousand callers may be worthwhile. Ten maintainers learning a difficult type to remove two lines at one call site usually is not.

4. Do error messages retain domain meaning? Errors should tell the caller which field is missing or which state is invalid, not merely expose type-system internals.

5. Is there an acceptable fallback? When input stops being a literal and becomes a plain string or dynamic array, the API should deliberately fall back to a broad but safe type, return unknown, or reject the call. It should not accidentally degrade to any.

6. Can compilation cost be measured and controlled? A type entering a shared foundation library should be monitored through diagnostics, traces, and type tests.

Not every question must receive an unqualified yes. The source of complexity, the beneficiaries, and the failure modes must all be explainable.

11. Different roles need different type strategies

Roles differ in call-site scale, rate of change, and compatibility obligations, so they should not use the same complexity standard:

Application code changes frequently, so complex types can easily obstruct product evolution. Shared infrastructure can carry more internal complexity, but it should pass the benefits to callers through encapsulation. Whatever the role, reconsider the boundary when the type system makes routine changes difficult for most engineers.

12. Conclusion: make invalid states difficult to represent, not types difficult to read

Advanced TypeScript types are powerful architectural tools.

They preserve information between inputs and outputs, generate new types from existing ones, eliminate error-prone duplicate declarations, and support completion, refactoring, and the discoverability of public APIs. Used well, they can make some invalid states fail to compile, exposing design and call-site errors earlier.

These benefits are not free. Complex types increase the costs of learning, error diagnosis, and compilation. They also add pressure to TypeScript-version compatibility and public-API evolution. When boundaries are unclear, teams may mistake compile-time type safety for runtime data safety.

A mature team should therefore seek not “the most precise type,” but a constraint precise enough to be useful while remaining understandable, maintainable, diagnosable, and evolvable.

A mature TypeScript architecture keeps type complexity where its benefit is clear, its boundary is explicit, and the team can maintain it over time.

Eight principles summarize the use of advanced TypeScript:

1. Prefer expressing stable relationships to displaying type tricks.

2. Prefer a simple caller experience to a clever-looking implementation.

3. Prefer inference, but do not fear explicit annotations at important boundaries.

4. Prefer named types and avoid repeatedly computing enormous anonymous types.

5. Prefer runtime validation for external data.

6. Measure compiler performance instead of optimizing by intuition.

7. Allow reasonable duplication; do not create incorrect coupling through inference.

8. A complex type is good design only when its long-term benefit covers its total cost.

Neither a stronger nor a simpler type system is automatically better. The final test is whether it reduces the cost of errors while still letting the team understand, maintain, and evolve the code.

13. Further reading

• TypeScript: Creating Types from Types

• TypeScript Design Goals

• TypeScript Performance Guide

• TypeScript Project References

• TypeScript 4.9: The satisfies Operator

• TypeScript 5.0: const Type Parameters

• Type-Level TypeScript

• Effective TypeScript: The Golden Rule of Generics