Effective TypeScript: 62 Specific Ways to Improve Your TypeScript

… in a nutshell

Florian Kromer

Follow

Feb 20 · 20 min read

My personal approach to the topic

In 2019 I had to decide wether to choose TypeScript or JavaScript for the frontend development of a web interface for a MVP in the industrial domain. In the backend I was sure not to go with TypeScript nor with JavaScript. In the frontend I was not quite sure wether to go with TypeScript or with JavaScript. I already implemented some JavaScript in personal website projects but I wouldn’t have not called myself a professional frontend developer. I knew however that the lack of typing can become a problem. However as long as little, easy logic would have to be developed and maintained in the frontend the lack of typing wouldn’t be that critical. However in case there would arise the need for more and more complex logic it would be better to stick to TypeScript for sure. Some more context: In addition I would have potentially decided for the wrong language for later projects in a quite quality demanding domain as well. I had to decide which language to choose before I was able to finish the book. I learned a lot from the Effective … book series (Effective Modern C++ and Effective Python) before. I decided to get Effective TypeScript: 62 specific ways to improve your use of TypeScript to learn as much as possible relevant in practice in as little as possible time.

There is nothing to add!

The book is structured in a manner which promotes to read it from start to end. It’s possible to read single hints (“items”) in arbitrary order. However I’d recommend to read it from start to end. At least for me the read would not have been such an eye opener otherwise.

The content is to the point. The items are categorized in sections. Almost all items address the type system. The hints are about topics which adds on top of JavaScript w.r.t. typing. This sounds boring but was very interesting for me w.r.t. code reliability, things which can go wrong in JavaScript but which can’t go wrong with TypeScript (if you don’t use Any). The implications of TypeScript code getting compiled to JavaScript code was extremly helpful as well (compile time vs. runtime). The differences to a dynamically typed, optionally type hinted Python and statically typed C++ was very interesting. However if you search a book which teaches about basics of TypeScript programming it’s probably not the right one for you. Most items have an explanation by means of one or several examples. In addition each item has a Things to remember section. As this post is meant to be a thought support for myself I’ll almost exclusivelly reference content from now on. However you’ll probably have to read the book in addition to get value from this post.

1. Getting to know TypeScript (Item1 to 5)
2. TypeScript’s Type System (Item 6 to 18)
3. Type Inference (Item 19 to 27)
4. Type Design (Item 28 to 37)
5. Working with any (Item 38 to 44)
6. Types Declarations and @types (Item 45 to 52)
7. Writing and running your code (Item 53 to 57)
8. Migrating your code (Item 58 to 62)

Item 1: Understand the Relationship Between TypeScript and JavaScript

Things to remember [Effective TypeScript, p. 6/7]:

• TypeScript is a superset of JavaScript. In other words, all JavaScript programs are already TypeScript programs. TypeScript has some syntax of its own, so TypeScript programs are not, in general, valid JavaScript programs.
• TypeScript adds a type system that models JavaScript’s runtime behavior and tries to spot code which will throw exceptions at runtime. But you shouldn’t expect it to flag every exception. It is possible for code to pass the type checker but still throw at runtime.
• While TypeScript’s type system largely models JavaScript behavior, there are some constructs that JavaScript allows but TypeScript chooses to bar, such as calling functions with the wrong number of arguments. This is largely a matter of taste.

Item 2: Know Which TypeScript Options You’re Using

Things to remember [Effective TypeScript, p. 9/10]:

• The TypeScript compiler includes several settings which affect core aspects of the language.
• Configure TypeScript using tsconfig.json rather than command-line options.
• Turn on noImplicitAny unless you are transitioning a JavaScript project to TypeScript.
• Use strictNullChecks to prevent “undefined is not an object”-style runtime errors.
• Aim to enable strict to get the most thorough checking that TypeScript can offer.

Item 3: Understand That Code Generation Is Independent of Types

Headlines:

• Code with Type Errors Can Produce Output
• You Cannot Check TypeScript Types at Runtime
• Type Operations Cannot A€ffect Runtime Values
• Runtime Types May Not Be the Same as Declared Types
• You Cannot Overload a Function Based on TypeScript Types
• TypeScript Types Have No E€ect on Runtime Performance

Things to remember [Effective TypeScript, p. 16]:

• Code generation is independent of the type system. This means that TypeScript types cannot affect the runtime behavior or performance of your code.
• It is possible for a program with type errors to produce code (“compile”).
• TypeScript types are not available at runtime. To query a type at runtime, you need some way to reconstruct it. Tagged unions and property checking are common ways to do this. Some constructs, such as class, introduce both a TypeScript type and a value that is available at runtime.

Item 4: Get Comfortable with Structural Typing

Things to remember [Effective TypeScript, p. 19/20]:

• Understand that JavaScript is duck typed and TypeScript uses structural typing to model this: values assignable to your interfaces might have properties beyond those explicitly listed in your type declarations. Types are not “sealed.”
• Be aware that classes also follow structural typing rules. You may not have an instance of the class you expect!
• Use structural typing to facilitate unit testing.

Item 5: Limit Use of the any Type

Headlines:

• There’s No Type Safety with any Types
• any Lets You Break Contracts
• There Are No Language Services for any Types
• any Types Mask Bugs When You Refactor Code
• any Hides Your Type Design
• any Undermines Con‚dence in the Type System

Things to remember [Effective TypeScript, p. 24]:

• The any type effectively silences the type checker and TypeScript language services. It can mask real problems, harm developer experience, and undermine confidence in the type system. Avoid using it when you can!

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

Things to remember [Effective TypeScript, p. 29]:

• Take advantage of the TypeScript language services by using an editor that can use them.
• Use your editor to build an intuition for how the type system works and how TypeScript infers types.
• Know how to jump into type declaration files to see how they model behavior.

Item 7: Think of Types as Sets of Values

Things to remember [Effective TypeScript, p. 35]:

• Think of types as sets of values (the type’s domain). These sets can either be finite(e.g., boolean or literal types) or infinite (e.g., number or string).
• TypeScript types form intersecting sets (a Venn diagram) rather than a strict hierarchy. Two types can overlap without either being a subtype of the other.
• Remember that an object can still belong to a type even if it has additional properties that were not mentioned in the type declaration.
• Type operations apply to a set’s domain. The intersection of A and Bis the intersection of A’s domain and B’s domain. For object types, this means that values in A& B have the properties of both A and B.
• Think of “extends,” “assignable to,” and “subtype of ” as synonyms for “subset of.”

Item 8: Know How to Tell Whether a Symbol Is in the Type Space or Value Space

Things to remember [Effective TypeScript, p. 40]:

• Know how to tell whether you’re in type space or value space while reading a TypeScript expression. Use the TypeScript playground to build an intuition for this.
• Every value has a type, but types do not have values. Constructs such as type and interface exist only in the type space.
• ”foo” might be a string literal, or it might be a string literal type. Be aware of this distinction and understand how to tell which it is.
• typeof, this, and many other operators and keywords have different meanings in type space and value space.
• Some constructs such as class or enum introduce both a type and a value.

Item 9: Prefer Type Declarations to Type Assertions

Things to remember [Effective TypeScript, p. 43]:

• Prefer type declarations (: Type) to type assertions (as Type).
• Know how to annotate the return type of an arrow function.
• Use type assertions and non-null assertions when you know something about types that TypeScript does not.

Item 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)

Things to remember [Effective TypeScript, p. 46]:

• Understand how object wrapper types are used to provide methods on primitive values. Avoid instantiating them or using them directly.
• Avoid TypeScript object wrapper types. Use the primitive types instead: string instead of String, number instead of Number, boolean instead of Boolean, symbol instead of Symbol, and bigint instead of BigInt.

Item 11: Recognize the Limits of Excess Property Checking

Things to remember [Effective TypeScript, p. 49]:

• When you assign an object literal to a variable or pass it as an argument to a function, it undergoes excess property checking.
• Excess property checking is an effective way to find errors, but it is distinct from the usual structural assignability checks done by the TypeScript type checker. Conflating these processes will make it harder for you to build a mental model of assignability.
• Be aware of the limits of excess property checking: introducing an intermediate variable will remove these checks.

Item 12: Apply Types to Entire Function Expressions When Possible

Things to remember [Effective TypeScript, p. 52]:

• Consider applying type annotations to entire function expressions, rather than to their parameters and return type.
• If you’re writing the same type signature repeatedly, factor out a function type or look for an existing one. If you’re a library author, provide types for commoncallbacks.
• Use typeof fn to match the signature of another function.

Item 13: Know the Di€erences Between type and interface

Things to remember [Effective TypeScript, p. 56]:

• Understand the differences and similarities between type and interface.
• Know how to write the same types using either syntax.
• In deciding which to use in your project, consider the established style and whether augmentation might be beneficial.

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

Things to remember [Effective TypeScript, p. 64]:

• The DRY (don’t repeat yourself) principle applies to types as much as it applies to logic.
• Name types rather than repeating them. Use extends to avoid repeating fields in interfaces.
• Build an understanding of the tools provided by TypeScript to map between types. These include keyof, typeof, indexing, and mapped types.
• Generic types are the equivalent of functions for types. Use them to map between types instead of repeating types. Use extends to constrain generic types.
• Familiarize yourself with generic types defined in the standard library such as Pick, Partial, and ReturnType.

Item 15: Use Index Signatures for Dynamic Data

Things to remember [Effective TypeScript, p. 67]:

• Use index signatures when the properties of an object cannot be known untilruntime — for example, if you’re loading them from a CSV file.
• Consider adding undefined to the value type of an index signature for safer access.
• Prefer more precise types to index signatures when possible: interfaces, Records, or mapped types.

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

Things to remember [Effective TypeScript, p. 70/71]:

• Understand that arrays are objects, so their keys are strings, not numbers. numberas an index signature is a purely TypeScript construct which is designed to help catch bugs.
• Prefer Array, tuple, or ArrayLike types to using number in an index signature yourself.

Item 17: Use readonly to Avoid Errors Associated with Mutation

Things to remember [Effective TypeScript, p. 77]:

• If your function does not modify its parameters then declare them readonly. This makes its contract clearer and prevents inadvertent mutations in its implementation.
• Use readonlyto prevent errors with mutation and to find the places in your code where mutations occur.
• Understand the difference between const and readonly.
• Understand that readonly is shallow.

Item 18: Use Mapped Types to Keep Values in Sync

Things to remember [Effective TypeScript, p. 80]:

• Use mapped types to keep related values and types synchronized.
• Consider using mapped types to force choices when adding new properties to an interface.

Item 19: Avoid Cluttering Your Code with Inferable Types

Things to remember [Effective TypeScript, p. 87]:

• Avoid writing type annotations when TypeScript can infer the same type.
• Ideally your code has type annotations in function/method signatures but not on local variables in their bodies.
• Consider using explicit annotations for object literals and function return types even when they can be inferred. This will help prevent implementation errors from surfacing in user code.

Item 20: Use Di€erent Variables for Di€erent Types

Things to remember [Effective TypeScript, p. 89/90]:

• While a variable’s value can change, its type generally does not.
• To avoid confusion, both for human readers and for the type checker, avoid reusing variables for differently typed values.

Item 21: Understand Type Widening

Things to remember [Effective TypeScript, p. 93]:

• Understand how TypeScript infers a type from a constant by widening it.
• Familiarize yourself with the ways you can affect this behavior: const, type annotations, context, and as const.

Item 22: Understand Type Narrowing

Things to remember [Effective TypeScript, p. 96]:

• Understand how TypeScript narrows types based on conditionals and other typesof control flow.
• Use tagged/discriminated unions and user-defined type guards to help the process of narrowing.

Item 23: Create Objects All at Once

Things to remember [Effective TypeScript, p. 99]:

• Prefer to build objects all at once rather than piecemeal. Use object spread({…a, …b}) to add properties in a type-safe way.
• Know how to conditionally add properties to an object.

Item 24: Be Consistent in Your Use of Aliases

Things to remember [Effective TypeScript, p. 102]:

• Aliasing can prevent TypeScript from narrowing types. If you create an alias for avariable, use it consistently.
• Use destructuring syntax to encourage consistent naming.
• Be aware of how function calls can invalidate type refinements on properties. Trust refinements on local variables more than on properties.

Item 25: Use async Functions Instead of Callbacks forAsynchronous Code

Things to remember [Effective TypeScript, p. 107]:

• Prefer Promises to callbacks for better composability and type flow.
• Prefer async and await to raw Promises when possible. They produce more con‐cise, straightforward code and eliminate whole classes of errors.
• If a function returns a Promise, declare it async.

Item 26: Understand How Context Is Used in TypeInference

Things to remember [Effective TypeScript, p. 111]:

• Be aware of how context is used in type inference.
• If factoring out a variable introduces a type error, consider adding a type declaration.
• If the variable is truly a constant, use a const assertion (as const). But be aware that this may result in errors surfacing at use, rather than definition.

Item 27: Use Functional Constructs and Libraries to HelpTypes Flow

Things to remember [Effective TypeScript, p. 115]:

• Use built-in functional constructs and those in utility libraries like Lodash instead of hand-rolled constructs to improve type flow, increase legibility, and reduce the need for explicit type annotations.

Item 28: Prefer Types That Always Represent Valid States

Things to remember [Effective TypeScript, p. 122]:

• Types that represent both valid and invalid states are likely to lead to confusing and error-prone code.
• Prefer types that only represent valid states. Even if they are longer or harder to express, they will save you time and pain in the end!

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

Things to remember [Effective TypeScript, p. 125]:

• Input types tend to be broader than output types. Optional properties and uniontypes are more common in parameter types than return types.
• To reuse types between parameters and return types, introduce a canonical form (for return types) and a looser form (for parameters).

Item 30: Don’t Repeat Type Information in Documentation

Things to remember [Effective TypeScript, p. 127]:

• Avoid repeating type information in comments and variable names. In the bestcase it is duplicative of type declarations, and in the worst it will lead to conflicting information.
• Consider including units in variable names if they aren’t clear from the type (e.g., timeMs or temperatureC).

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

Things to remember [Effective TypeScript, p. 130]:

• Avoid designs in which one value being null or not null is implicitly related to another value being null or not null.
• Push null values to the perimeter of your API by making larger objects either null or fully non-null. This will make code clearer both for human readers and for the type checker.
• Consider creating a fully non-null class and constructing it when all values are available.
• While strictNullChecks may flag many issues in your code, it’s indispensable for surfacing the behavior of functions with respect to null values.

Item 32: Prefer Unions of Interfaces to Interfaces of Unions

Things to remember [Effective TypeScript, p. 134]:

• Interfaces with multiple properties that are union types are often a mistakebecause they obscure the relationships between these properties.
• Unions of interfaces are more precise and can be understood by TypeScript.
• Consider adding a “tag” to your structure to facilitate TypeScript’s control flow analysis. Because they are so well supported, tagged unions are ubiquitous in TypeScript code.

Item 33: Prefer More Precise Alternatives to String Types

Things to remember [Effective TypeScript, p. 138]:

• Avoid “stringly typed” code. Prefer more appropriate types where not everystring is a possibility.
• Prefer a union of string literal types to stringif that more accurately describes the domain of a variable. You’ll get stricter type checking and improve the development experience.
• Prefer keyof T to string for function parameters that are expected to be properties of an object.

Item 34: Prefer Incomplete Types to Inaccurate Types

Things to remember [Effective TypeScript, p. 142]:

• Avoid the uncanny valley of type safety: incorrect types are often worse than no types.
• If you cannot model a type accurately, do not model it inaccurately! Acknowledge the gaps using any or unknown.
• Pay attention to error messages and autocomplete as you make typings increasingly precise. It’s not just about correctness: developer experience matters, too.

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

Things to remember [Effective TypeScript, p. 147]:

• Consider generating types for API calls and data formats to get type safety all the way to the edge of your code.
• Prefer generating code from specs rather than data. Rare cases matter!

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

Things to remember [Effective TypeScript, p. 149]:

• Reuse names from the domain of your problem where possible to increase the readability and level of abstraction of your code.
• Avoid using different names for the same thing: make distinctions in names meaningful.

Item 37: Consider “Brands” for Nominal Typing

Things to remember [Effective TypeScript, p. 152]:

• TypeScript uses structural (“duck”) typing, which can sometimes lead to surprising results. If you need nominal typing, consider attaching “brands” to your values to distinguish them.
• In some cases you may be able to attach brands entirely in the type system, rather than at runtime. You can use this technique to model properties outside of TypeScript’s type system.

Item 38: Use the Narrowest Possible Scope for any Types

Things to remember [Effective TypeScript, p. 155]:

• Make your uses of any as narrowly scoped as possible to avoid undesired loss of type safety elsewhere in your code.
• Never return an any type from a function. This will silently lead to the loss of type safety for any client calling the function.
• Consider @ts-ignore as an alternative to any if you need to silence one error.

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

Things to remember [Effective TypeScript, p. 157]:

• When you use any, think about whether any JavaScript value is truly permissible.
• Prefer more precise forms of any such as any[] or {[id: string]: any}or ()=> any if they more accurately model your data.

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

Things to remember [Effective TypeScript, p. 159]:

• Sometimes unsafe type assertions are necessary or expedient. When you need to use one, hide it inside a function with a correct signature.

Item 41: Understand Evolving any

Things to remember [Effective TypeScript, p. 162]:

• While TypeScript types typically only refine, implicit any and any[] types are allowed to evolve. You should be able to recognize and understand this construct where it occurs.
• For better error checking, consider providing an explicit type annotation instead of using evolving any.

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

Things to remember [Effective TypeScript, p. 165/166]:

• The unknown type is a type-safe alternative to any. Use it when you know youhave a value but do not know what its type is.
• Use unknown to force your users to use a type assertion or do type checking.
• Understand the difference between {}, object, and unknown.

Item 43: Prefer Type-Safe Approaches to Monkey Patching

Things to remember [Effective TypeScript, p. 168]:

• Prefer structured code to storing data in globals or on the DOM.
• If you must store data on built-in types, use one of the type-safe approaches (augmentation or asserting a custom interface).
• Understand the scoping issues of augmentations.

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

Things to remember [Effective TypeScript, p. 170]:

• Even with noImplicitAny set, anytypes can make their way into your code eitherthrough explicit anys or third-party type declarations (@types).
• Consider tracking how well-typed your program is. This will encourage you to revisit decisions about using any and increase type safety over time.

Item 45: Put TypeScript and @types in devDependencies

Things to remember [Effective TypeScript, p. 173]:

• Avoid installing TypeScript system-wide. Make TypeScript a devDependency of your project to ensure that everyone on the team is using a consistent version.
• Put @types dependencies in devDependencies, not dependencies. If you need @types at runtime, then you may want to rework your process.

Item 46: Understand the Three Versions Involved in TypeDeclarations

Things to remember [Effective TypeScript, p. 177]:

• There are three versions involved in an @types dependency: the library version, the @types version, and the TypeScript version.
• If you update a library, make sure you update the corresponding @types.
• Understand the pros and cons of bundling types versus publishing them on DefinitelyTyped. Prefer bundling types if your library is written in TypeScript and DefinitelyTyped if it is not.

Item 47: Export All Types That Appear in Public APIs

Things to remember [Effective TypeScript, p. 178]:

• Export types that appear in any form in any public method. Your users will beable to extract them anyway, so you may as well make it easy for them.

Item 48: Use TSDoc for API Comments

Things to remember [Effective TypeScript, p. 181]:

• Use JSDoc-/TSDoc-formatted comments to document exported functions,classes, and types. This helps editors surface information for your users when it’smost relevant.
• Use @param, @returns, and Markdown for formatting.
• Avoid including type information in documentation (see Item 30).

Item 49: Provide a Type for this in Callbacks

Things to remember [Effective TypeScript, p. 181]:

• Understand how this binding works.
• Provide a type for this in callbacks when it’s part of your API.

Item 50: Prefer Conditional Types to OverloadedDeclarations

Things to remember [Effective TypeScript, p. 187]:

• Prefer conditional types to overloaded type declarations. By distributing over unions, conditional types allow your declarations to support union types without additional overloads.

Item 51: Mirror Types to Sever Dependencies

Things to remember [Effective TypeScript, p. 188]:

• Use structural typing to sever dependencies that are nonessential.
• Don’t force JavaScript users to depend on @types. Don’t force web developers todepend on NodeJS.

Item 52: Be Aware of the Pitfalls of Testing Types

Things to remember [Effective TypeScript, p. 192/193]:

• When testing types, be aware of the difference between equality and assignability, particularly for function types.
• For functions that use callbacks, test the inferred types of the callback parameters. Don’t forget to test the type of this if it’s part of your API.
• Be wary of any in tests involving types. Consider using a tool like dtslintforstricter, less error-prone checking.

Item 53: Prefer ECMAScript Features to TypeScriptFeatures

Things to remember [Effective TypeScript, p. 200]:

• By and large, you can convert TypeScript to JavaScript by removing all the types from your code.
• Enums, parameter properties, triple-slash imports, and decorators are historicalexceptions to this rule.
• In order to keep TypeScript’s role in your codebase as clear as possible, I recommend avoiding these features.

Item 54: Know How to Iterate Over Objects

Things to remember [Effective TypeScript, p. 202]:

• Use let k: keyof T and a for-in loop to iterate objects when you know exactlywhat the keys will be. Be aware that any objects your function receives as parame‐ters might have additional keys.
• Use Object.entries to iterate over the keys and values of any object.

Item 55: Understand the DOM hierarchy

Things to remember [Effective TypeScript, p. 202]:

• The DOM has a type hierarchy that you can usually ignore while writing JavaScript. But these types become more important in TypeScript. Understanding them will help you write TypeScript for the browser.
• Know the differences between Node, Element, HTMLElement, and EventTarget, aswell as those between Event and MouseEvent.
• Either use a specific enough type for DOM elements and Events in your code or give TypeScript the context to infer it.

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

Things to remember [Effective TypeScript, p. 209]:

• The private access modifier is only enforced through the type system. It has no effect at runtime and can be bypassed with an assertion. Don’t assume it will keep data hidden.
• For more reliable information hiding, use a closure.

Item 57: Use Source Maps to Debug TypeScript

Things to remember [Effective TypeScript, p. 214]:

• Don’t debug generated JavaScript. Use source maps to debug your TypeScript code at runtime.
• Make sure that your source maps are mapped all the way through to the code that you run.
• Depending on your settings, your source maps might contain an inline copy of your original code. Don’t publish them unless you know what you’re doing!

Item 58: Write Modern JavaScript

Headlines:

• Use ECMAScript Modules
• Use Classes Instead of Prototypes
• Use let/const Instead of var
• Use for-of or Array Methods Instead of for(;;)
• Prefer Arrow Functions Over Function Expressions
• Use Compact Object Literals and Destructuring Assignment
• Use Default Function Parameters
• Use async/await Instead of Raw Promises or Callbacks
• Don’t Put use strict in TypeScript

Things to remember [Effective TypeScript, p. 223]:

• TypeScript lets you write modern JavaScript whatever your runtime environment. Take advantage of this by using the language features it enables. In addition 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

Things to remember [Effective TypeScript, p. 227/228]:

• Add “// @ts-check” to the top of a JavaScript file to enable type checking.
• Recognize common errors. Know how to declare globals and add type declara‐tions for third-party libraries.
• Use JSDoc annotations for type assertions and better type inference.
• Don’t spend too much time getting your code perfectly typed with JSDoc.Remember that the goal is to convert to .ts!

Item 60: Use allowJs to Mix TypeScript and JavaScript

Things to remember [Effective TypeScript, p. 229]:

• Use the allowJs compiler option to support mixed JavaScript and TypeScript as you transition your project.
• Get your tests and build chain working with TypeScript before beginning largescale migration.

Item 61: Convert Module by Module Up Your DependencyGraph

Things to remember [Effective TypeScript, p. 233/234]:

• Start migration by adding @types for third-party modules and external API calls.
• Begin migrating your modules from the bottom of the dependency graph upwards. The first module will usually be some sort of utility code. Consider visualizing the dependency graph to help you track progress.
• Resist the urge to refactor your code as you uncover odd designs. Keep a list ofideas for future refactors, but stay focused on TypeScript conversion.
• Be aware of common errors that come up during conversion. Copy JSDoc annotations if necessary to avoid losing type safety as you convert.

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

Things to remember [Effective TypeScript, p. 235]:

• Don’t consider your TypeScript migration done until you adopt noImplicitAny. Loose type checking can mask real mistakes in type declarations.
• Fix type errors gradually before enforcing noImplicitAny. Give your team a chance to get comfortable with TypeScript before adopting stricter checks.

Reference

• [Effective TypeScript]: Vanderkam, Dan, ed. (2019) Effective TypeScript: 62 Speci€c Ways to Improve Your TypeScript. 1st ed. Sebastopol: O’Reilly

Happy reading :)