book

Effective TypeScript

by Dan Vanderkam

October 2019

Intermediate to advanced

261 pages

6h 14m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

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
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 Declarations to Type AssertionsItem 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)Item 11: Recognize the Limits of Excess Property CheckingItem 12: Apply Types to Entire Function Expressions When PossibleItem 13: Know the Differences Between type and interfaceItem 14: Use Type Operations and Generics to Avoid Repeating YourselfItem 15: Use Index Signatures for Dynamic DataItem 16: Prefer Arrays, Tuples, and ArrayLike to number Index SignaturesItem 17: Use readonly to Avoid Errors Associated with MutationItem 18: Use Mapped Types to Keep Values in Sync
Item 19: Avoid Cluttering Your Code with Inferable TypesItem 20: Use Different Variables for Different TypesItem 21: Understand Type WideningItem 22: Understand Type NarrowingItem 23: Create Objects All at OnceItem 24: Be Consistent in Your Use of AliasesItem 25: Use async Functions Instead of Callbacks for Asynchronous CodeItem 26: Understand How Context Is Used in Type InferenceItem 27: Use Functional Constructs and Libraries to Help Types Flow
Item 28: Prefer Types That Always Represent Valid StatesItem 29: Be Liberal in What You Accept and Strict in What You ProduceItem 30: Don’t Repeat Type Information in DocumentationItem 31: Push Null Values to the Perimeter of Your TypesItem 32: Prefer Unions of Interfaces to Interfaces of UnionsItem 33: Prefer More Precise Alternatives to String TypesItem 34: Prefer Incomplete Types to Inaccurate TypesItem 35: Generate Types from APIs and Specs, Not DataItem 36: Name Types Using the Language of Your Problem DomainItem 37: Consider “Brands” for Nominal Typing
Item 38: Use the Narrowest Possible Scope for any TypesItem 39: Prefer More Precise Variants of any to Plain anyItem 40: Hide Unsafe Type Assertions in Well-Typed FunctionsItem 41: Understand Evolving anyItem 42: Use unknown Instead of any for Values with an Unknown TypeItem 43: Prefer Type-Safe Approaches to Monkey PatchingItem 44: Track Your Type Coverage to Prevent Regressions in Type Safety
Item 45: Put TypeScript and @types in devDependenciesItem 46: Understand the Three Versions Involved in Type DeclarationsItem 47: Export All Types That Appear in Public APIsItem 48: Use TSDoc for API CommentsItem 49: Provide a Type for this in CallbacksItem 50: Prefer Conditional Types to Overloaded DeclarationsItem 51: Mirror Types to Sever DependenciesItem 52: Be Aware of the Pitfalls of Testing Types
Item 53: Prefer ECMAScript Features to TypeScript FeaturesItem 54: Know How to Iterate Over ObjectsItem 55: Understand the DOM hierarchyItem 56: Don’t Rely on Private to Hide InformationItem 57: Use Source Maps to Debug TypeScript
Item 58: Write Modern JavaScriptItem 59: Use @ts-check and JSDoc to Experiment with TypeScriptItem 60: Use allowJs to Mix TypeScript and JavaScriptItem 61: Convert Module by Module Up Your Dependency GraphItem 62: Don’t Consider Migration Complete Until You Enable noImplicitAny

Content preview from Effective TypeScript

Chapter 6. Types Declarations and @types

Dependency management can be confusing in any language, and TypeScript is no exception. This chapter will help you build a mental model for how dependencies work in TypeScript and show you how to work through some of the issues that can come up with them. It will also help you craft your own type declaration files to publish and share with others. By writing great type declarations, you can help not just your own project but the entire TypeScript community.

Item 45: Put TypeScript and @types in devDependencies

The Node Package Manager, npm, is ubiquitous in the JavaScript world. It provides both a repository of JavaScript libraries (the npm registry) and a way to specify which versions of them you depend on (package.json).

npm draws a distinction between a few types of dependencies, each of which goes in a separate section of package.json:

dependencies: These are packages that are required to run your JavaScript. If you import lodash at runtime, then it should go in dependencies. When you publish your code on npm and another user installs it, it will also install these dependencies. (These are known as transitive dependencies.)
devDependencies: These packages are used to develop and test your code but are not required at runtime. Your test framework would be an example of a devDependency. Unlike dependencies, these are not installed transitively with your packages.
peerDependencies: These are packages that you require at runtime but ...