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 9. Writing and Running Your Code

This chapter is a bit of a grab bag: it covers some issues that come up in writing code (not types) as well as issues you may run into when you run your code.

Item 72: Prefer ECMAScript Features to TypeScript Features

The relationship between TypeScript and JavaScript has changed over time. When Microsoft first started work on TypeScript in 2010, the prevailing attitude around JavaScript was that it was a problematic language that needed to be fixed. It was common for frameworks and source-to-source compilers to add missing features like classes, decorators, and a module system to JavaScript. TypeScript was no different. Early versions included home-grown versions of classes, enums, and modules.

Over time, TC39, the standards body that governs JavaScript, added many of these same features to the core JavaScript language. And the features they added were not compatible with the versions that existed in TypeScript. This left the TypeScript team in an awkward predicament: adopt the new features from the standard or maintain existing code?

TypeScript has largely chosen to do the former and eventually articulated its current governing principle: TC39 defines the runtime, while TypeScript innovates solely in the type space.

There are a few remaining features from before this decision. It’s important to recognize and understand these, because they don’t fit the pattern of the rest of the language. In general, I recommend avoiding them to keep ...