Issuu

Effective TypeScript

But as you transition to TypeScript, there’s not much value in keeping 'use strict' in your source code. By and large, the sanity checks that TypeScript provides are far stricter than those offered by strict mode. There is some value in having a 'use strict' in the JavaScript that tsc emits. If you set the alwaysStrict or strict compiler options, TypeScript will parse your code in strict mode and put a 'use strict' in the JavaScript output for you. In short, don’t write 'use strict' in your TypeScript. Use alwaysStrict instead. These are just a few of the many new JavaScript features that TypeScript lets you use. TC39, the body that governs JS standards, is very active, and new features are added year to year. The TypeScript team is currently committed to implementing any fea‐ ture that reaches stage 3 (out of 4) in the standardization process, so you don’t even have to wait for the ink to dry. Check out the TC39 GitHub repo3 for the latest. As of this writing, the pipeline and decorators proposals in particular have great potential to impact TypeScript.

Things to Remember • TypeScript lets you write modern JavaScript whatever your runtime environ‐ ment. Take advantage of this by using the language features it enables. In addi‐ tion to improving your codebase, this will help TypeScript understand your code. • Use TypeScript to learn language features like classes, destructuring, and async/ await. • Don’t bother with 'use strict': TypeScript is stricter. • Check the TC39 GitHub repo and TypeScript release notes to learn about all the latest language features.

Item 59: Use @ts-check and JSDoc to Experiment with TypeScript Before you begin the process of converting your source files from JavaScript to Type‐ Script (Item 60), you may want to experiment with type checking to get an initial read on the sorts of issues that will come up. TypeScript’s @ts-check directive lets you do exactly this. It directs the type checker to analyze a single file and report whatever issues it finds. You can think of it as an extremely loose version of type checking: looser even than TypeScript with noImplicitAny off (Item 2).

3 https://github.com/tc39/proposals

Item 59: Use @ts-check and JSDoc to Experiment with TypeScript

223

Effective TypeScript

Articles inside

Item 62: Don’t Consider Migration Complete Until You Enable noImplicitAny

Item 61: Convert Module by Module Up Your Dependency Graph

Item 60: Use allowJs to Mix TypeScript and JavaScript

Item 59: Use @ts-check and JSDoc to Experiment with TypeScript

Item 58: Write Modern JavaScript

Item 57: Use Source Maps to Debug TypeScript

Item 56: Don’t Rely on Private to Hide Information

Item 54: Know How to Iterate Over Objects

Item 53: Prefer ECMAScript Features to TypeScript Features

Item 55: Understand the DOM hierarchy

Item 52: Be Aware of the Pitfalls of Testing Types

Item 51: Mirror Types to Sever Dependencies

Item 50: Prefer Conditional Types to Overloaded Declarations

Item 49: Provide a Type for this in Callbacks

Item 48: Use TSDoc for API Comments

Item 45: Put TypeScript and @types in devDependencies

Item 46: Understand the Three Versions Involved in Type Declarations

Item 44: Track Your Type Coverage to Prevent Regressions in Type Safety

Item 42: Use unknown Instead of any for Values with an Unknown Type

Item 43: Prefer Type-Safe Approaches to Monkey Patching

Item 41: Understand Evolving any

Item 40: Hide Unsafe Type Assertions in Well-Typed Functions

Item 38: Use the Narrowest Possible Scope for any Types

Item 39: Prefer More Precise Variants of any to Plain any

Item 37: Consider “Brands” for Nominal Typing

Item 34: Prefer Incomplete Types to Inaccurate Types

Item 36: Name Types Using the Language of Your Problem Domain

Item 35: Generate Types from APIs and Specs, Not Data

Item 33: Prefer More Precise Alternatives to String Types

Item 32: Prefer Unions of Interfaces to Interfaces of Unions

Item 29: Be Liberal in What You Accept and Strict in What You Produce

Item 30: Don’t Repeat Type Information in Documentation

Item 31: Push Null Values to the Perimeter of Your Types

Item 26: Understand How Context Is Used in Type Inference

Item 28: Prefer Types That Always Represent Valid States

Item 27: Use Functional Constructs and Libraries to Help Types Flow

Item 25: Use async Functions Instead of Callbacks for Asynchronous Code

Item 20: Use Different Variables for Different Types

Item 18: Use Mapped Types to Keep Values in Sync

Item 21: Understand Type Widening

Item 24: Be Consistent in Your Use of Aliases

Item 17: Use readonly to Avoid Errors Associated with Mutation

Item 22: Understand Type Narrowing

Item 19: Avoid Cluttering Your Code with Inferable Types

Item 23: Create Objects All at Once

Item 13: Know the Differences Between type and interface

BigInt

Item 12: Apply Types to Entire Function Expressions When Possible

Item 16: Prefer Arrays, Tuples, and ArrayLike to number Index Signatures

Item 14: Use Type Operations and Generics to Avoid Repeating Yourself

Item 15: Use Index Signatures for Dynamic Data

Item 11: Recognize the Limits of Excess Property Checking

Item 9: Prefer Type Declarations to Type Assertions Item 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol,

Item 5: Limit Use of the any Type

Item 2: Know Which TypeScript Options You’re Using

Space

Item 1: Understand the Relationship Between TypeScript and JavaScript

Item 4: Get Comfortable with Structural Typing

Item 7: Think of Types as Sets of Values Item 8: Know How to Tell Whether a Symbol Is in the Type Space or Value

Item 6: Use Your Editor to Interrogate and Explore the Type System

Item 3: Understand That Code Generation Is Independent of Types