book

Effective TypeScript, 2nd Edition

by Dan Vanderkam

April 2024

Beginner to intermediate

404 pages

10h 6m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Includes

Has Sandbox

Who This Book Is ForWhy I Wrote This BookHow This Book Is OrganizedConventions in TypeScript Code SamplesTypographical Conventions Used in This BookUsing Code ExamplesO’Reilly Online LearningHow to Contact UsAcknowledgments
Acknowledgments to the First Edition
Item 1: Understand the Relationship Between TypeScript and JavaScriptItem 2: Know Which TypeScript Options You’re UsingItem 3: Understand That Code Generation Is Independent of TypesItem 4: Get Comfortable with Structural TypingItem 5: Limit Use of the any Type
Item 6: Use Your Editor to Interrogate and Explore the Type SystemItem 7: Think of Types as Sets of ValuesItem 8: Know How to Tell Whether a Symbol Is in the Type Space or Value SpaceItem 9: Prefer Type Annotations to Type AssertionsItem 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)Item 11: Distinguish Excess Property Checking from Type CheckingItem 12: Apply Types to Entire Function Expressions When PossibleItem 13: Know the Differences Between type and interfaceItem 14: Use readonly to Avoid Errors Associated with MutationItem 15: Use Type Operations and Generic Types to Avoid Repeating YourselfItem 16: Prefer More Precise Alternatives to Index SignaturesItem 17: Avoid Numeric Index Signatures
Item 18: Avoid Cluttering Your Code with Inferable TypesItem 19: Use Different Variables for Different TypesItem 20: Understand How a Variable Gets Its TypeItem 21: Create Objects All at OnceItem 22: Understand Type NarrowingItem 23: Be Consistent in Your Use of AliasesItem 24: Understand How Context Is Used in Type InferenceItem 25: Understand Evolving TypesItem 26: Use Functional Constructs and Libraries to Help Types FlowItem 27: Use async Functions Instead of Callbacks to Improve Type FlowItem 28: Use Classes and Currying to Create New Inference Sites
Item 29: Prefer Types That Always Represent Valid StatesItem 30: Be Liberal in What You Accept and Strict in What You ProduceItem 31: Don’t Repeat Type Information in DocumentationItem 32: Avoid Including null or undefined in Type AliasesItem 33: Push Null Values to the Perimeter of Your TypesItem 34: Prefer Unions of Interfaces to Interfaces with UnionsItem 35: Prefer More Precise Alternatives to String TypesItem 36: Use a Distinct Type for Special ValuesItem 37: Limit the Use of Optional PropertiesItem 38: Avoid Repeated Parameters of the Same TypeItem 39: Prefer Unifying Types to Modeling DifferencesItem 40: Prefer Imprecise Types to Inaccurate TypesItem 41: Name Types Using the Language of Your Problem DomainItem 42: Avoid Types Based on Anecdotal Data
Item 43: Use the Narrowest Possible Scope for any TypesItem 44: Prefer More Precise Variants of any to Plain anyItem 45: Hide Unsafe Type Assertions in Well-Typed FunctionsItem 46: Use unknown Instead of any for Values with an Unknown TypeItem 47: Prefer Type-Safe Approaches to Monkey PatchingItem 48: Avoid Soundness TrapsItem 49: Track Your Type Coverage to Prevent Regressions in Type Safety
Item 50: Think of Generics as Functions Between TypesItem 51: Avoid Unnecessary Type ParametersItem 52: Prefer Conditional Types to Overload SignaturesItem 53: Know How to Control the Distribution of Unions over Conditional TypesItem 54: Use Template Literal Types to Model DSLs and Relationships Between StringsItem 55: Write Tests for Your TypesItem 56: Pay Attention to How Types DisplayItem 57: Prefer Tail-Recursive Generic TypesItem 58: Consider Codegen as an Alternative to Complex Types
Item 59: Use Never Types to Perform Exhaustiveness CheckingItem 60: Know How to Iterate Over ObjectsItem 61: Use Record Types to Keep Values in SyncItem 62: Use Rest Parameters and Tuple Types to Model Variadic FunctionsItem 63: Use Optional Never Properties to Model Exclusive OrItem 64: Consider Brands for Nominal Typing
Item 65: Put TypeScript and @types in devDependenciesItem 66: Understand the Three Versions Involved in Type DeclarationsItem 67: Export All Types That Appear in Public APIsItem 68: Use TSDoc for API CommentsItem 69: Provide a Type for this in Callbacks if It’s Part of Their APIItem 70: Mirror Types to Sever DependenciesItem 71: Use Module Augmentation to Improve Types

Item 72: Prefer ECMAScript Features to TypeScript FeaturesItem 73: Use Source Maps to Debug TypeScriptItem 74: Know How to Reconstruct Types at RuntimeItem 75: Understand the DOM HierarchyItem 76: Create an Accurate Model of Your EnvironmentItem 77: Understand the Relationship Between Type Checking and Unit TestingItem 78: Pay Attention to Compiler Performance
Item 79: Write Modern JavaScriptItem 80: Use @ts-check and JSDoc to Experiment with TypeScriptItem 81: Use allowJs to Mix TypeScript and JavaScriptItem 82: Convert Module by Module Up Your Dependency GraphItem 83: Don’t Consider Migration Complete Until You Enable noImplicitAny

Content preview from Effective TypeScript, 2nd Edition

Chapter 5. Unsoundness and the any Type

Type systems were traditionally binary affairs: either a language had a fully static type system or a fully dynamic one. TypeScript blurs the line, because its type system is optional and gradual. You’re free to add types to parts of your program but not others.

This is essential for migrating existing JavaScript codebases to TypeScript bit by bit (Chapter 10). Key to this is the any type, which effectively disables type checking for parts of your code. It is both powerful and prone to abuse. Learning to use any wisely is essential for writing effective TypeScript. This chapter walks you through how to limit the downsides of any while still retaining its benefits.

The any type is just the most extreme example of the more general problem of unsoundness: when a symbol’s static type does not match its runtime type. Even if you eliminate all the anys from your code, you may still fall into soundness traps. Item 48 presents a few of these and shows you how to avoid them.

Item 43: Use the Narrowest Possible Scope for any Types

Consider this code:

declare function getPizza(): Pizza;
function eatSalad(salad: Salad) { /* ... */ }

function eatDinner() {
  const pizza = getPizza();
  eatSalad(pizza);
  //       ~~~~~
  // Argument of type 'Pizza' is not assignable to parameter of type 'Salad'
  pizza.slice();
}

If you somehow know that this call to eatSalad is OK, the best way forward is to adjust your types so that TypeScript understands that, too. (An arugula pizza ...