I know that we should define a consistent typing method throughout the codebase to ensure the use of the same approach

Type vs interface

I know that non-primitive boxed objects like *String* (not *string*) should never be used

I understand that I should avoid using *any* and *object*

Do not use

I know that we should establish consistent rules for typing function types within specific parts of the code. I understand the impact of the decision between inferred and typed return types on **refactoring** and the **consistency** of utilities

I'm aware that I need to include return types for recursive functions

Function return types

I know I should mostly use tuples when returning fixed-length arrays

Use tuples

There are some practices that are highly recommended to be considered **as a standard** within your codebase. They will affect future refactors and help maintain a healthy state of the type system.

> TypeScript truly shines when the entire codebase is strictly typed.
> ????
> *2023, author of this roadmap*


Best practices and conventions

I know that in TypeScript, you can use basic types such as **number**, **string**, **boolean**, **null**, and **undefined**

I am aware that in JavaScript, there is no distinction between integers and floating-point numbers

Basic data types

I know that I can use a value (e.g., string or number) to create a specific type

Value as type

I know I can use the `|` symbol to create union types that will accept one of the allowed types as the value of the variable.

Union types

I know that I can create a type that accepts an array of elements of a specific type using the `...[]` or `Array<...>` syntax

Arrays

I know that I can create tuples and I know how they are different from array types

Tuples

To start with TypeScript, you must know the basic types available specifically for JavaScript. Every more complex structure will be built composed of the basic types.

These foundations will enable you to create more complex, real-life types.

Basics

[TypeScript](https://www.typescriptlang.org/) is a meta-language that adds syntax to [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) to support a **tighter integration with your IDE**. It enables you to detect early errors within your code and greatly assists with code refactoring.

To work with TypeScript, you will need to have a **solid foundation** in JavaScript, as TypeScript is an additional layer added to this language.

Prerequisites

I know how to create a function type, and I remember to specify the types of arguments (if present) and the return value type

Function type

I know how to specify the return type, and I use **void** keyword to indicate functions that are not expected to return anything

Return value

I know how to type a function that can accept any number of arguments of a specific type using the `(...rest: T[]) => ReturnValue` spread syntax

Spread arguments

I know that I can mark a function as asynchronous by using the `Promise<>` wrapper on the returned value

Async functions

I know how to properly type an argument that is expected to be a function. I also know that I can pass a function with different type as an argument as long as the types are **overlapping**

Function as argument

The **major part** of typing will happen for the functions and their **arguments**. Usually, TypeScript will be able to detect the expected type of variables based on their initialization. However, functions will **always** require input type definitions.

The argument of a function can also be a function, so you will need to understand how function type overlaps work.

Functions

I can define simple object types, including objects containing optional keys

Object type

I know how I can create a type that will have a dynamic keys using **index signature** or **Record** utility type

Generic object type

I know how to mark specific object keys as readonly properties

Readonly keys

I know what will be a result of types' intersection (**&** operator)

I understand how the final type is generated based on the keys and value types of the intersected types

Intersection of objects

I know that I can access the type of a specific property of an object type and reuse it

Lookup types

In JavaScript, almost everything is an object. You need to know how to define an object's type to handle them safely inside your code

Objects

I know that I can use the **any** keyword to mark a variable that will accept basically **anything**.

I also understand that **as** can be used to **force** the type of a variable.

However, I am aware that using these types **should be avoided**, as it neglects all the benefits provided by TypeScript. Nevertheless, I understand that there are some cases where *any* and *as* can be necessary, as sometimes TypeScript will not be able to fully detect type narrowing.

Keywords - any and as

I understand the **never** and **unknown** keywords and their differences

I also know that for an unknown variable, it is better to mark it as **unknown** rather than **any** to enforce proper handling within the codebase

Keywords - never and unknown

I know that I can create types based on existing variables using **typeof** and **keyof**.

I understand that these keywords are based on static code analysis (not runtime type detection)

Keywords - typeof and keyof

I know that I can mark an array or object as immutable using **as const**

I understand that it marks both the variable and its values as **readonly**

Keyword - as const

I know when to use the **satisfies** keyword. I know this feature has been available since TypeScript 4.9

Keyword - satisfies

There are a few keywords specific to TypeScript. They either **extend basic** types bound to the data types available inside JavaScript or provide options to work with existing values in order to create types based on them.

Each of them has specific use cases where they come in really handy.

TS keywords

I can interchangeably switch between **interface** and **type** syntax to describe the type of an object

I know the syntax for interfaces and how to **extend** existing ones

Interface

I know that the main difference between interfaces and types is the **declaration merging** mechanism

I understand the drawbacks and advantages of this mechanism and why it can be both useful and harmful depending on the needs and architecture of the code

Declaration merging

There are two main tools for declaring the shape of an object: **interfaces** and **type** aliases. They are very similar and, for the most common cases, they behave the same way.

However, there are some differences between these two syntaxes. There used to be more differences, but since TypeScript version 4+, both support extending other interfaces and types.

**Some edge cases**
- the inability to extend an interface from a type created using the **|** operator
- instead of **intersection** operation, there is a special **extends** keyword
- different error messages between types and interfaces
- interfaces are open on modification while types are closed

Interface vs type

I know how to narrow basic types like string, number, and boolean using the **typeof** check

I know that to detect null and undefined variables, all I need is **===**

Basic types narrowing

I know that I can use the **Array.isArray** utility to narrow down the type to an array

Array detection

I know that I can use **typeof** operator to check for object but I'm aware that I need an additional check for null value

Object detection

I know that object type detection is a more complex operation. I understand that checking for the existence of keys with the **in** operator or their value may **not be sufficient**.

I also know about the **type guard** technique that helps with code expecting multiple different types of objects.

Different object types

I know that I can use **instanceof** operator to check if variable is a specific class type. I know how inheritance affects results of this check

Class detection

When dealing with unions and intersections of different types, you will often need to **handle each of the cases** with some adjustments inside your code. TypeScript is going to take care not to miss any edge cases.

To handle each type separately, you need to know how to detect specific types. You need to perform the check so the TypeScript will be able to **detect narrowed variable type** inside the branch.

Type detection

I know I can create a transformed type based on the object type values using **Partial**, **Required** and **Readonly**

Object values transformation

I know how to create a new type containing only part of the keys using **Pick** and **Omit** operators

Object parts

I use **Parameters** to access the list of parameter types

I use **ReturnType** to check what type is returned from a specific function type

Function transformation

I know when to use **Exclude**, **Extract**, and **NonNullable** utilities to narrow union elements from an existing one

Union transformations

TypeScript has **built-in** utilities that enable the creation of modified types based on existing types. Using these utilities helps you **maintain relationships** between dependent types, which can be valuable during **future refactoring**.

It's advisable to consider using utility types in places where you would otherwise create a new type by copying and pasting parts from an existing one.

Utility types

I know that I can adjust how strictly TypeScript checks the code

I am aware of the recommended setup, which includes [strict](https://www.typescriptlang.org/tsconfig#strict), [exactOptionalPropertyTypes](https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes), and [forceConsistentCasingInFileNames](https://www.typescriptlang.org/tsconfig#forceConsistentCasingInFileNames) options

I also understand how to modify the strictness of external libraries using the [skipLibCheck](https://www.typescriptlang.org/tsconfig#skipLibCheck)

Strictness

I know that I can add additional type sources using the [typeRoots](https://www.typescriptlang.org/tsconfig#typeRoots) configuration or use `include` with **.d.ts** files

I understand that this approach should be used for unsupported out-of-the-box imports, such as **.css** or libraries without **@types** packages

Extending available types

I know that I can define which files will be checked and included inside the build using various options inside the **tsconfig.json**

I can use a combination of [include](https://www.typescriptlang.org/tsconfig#include), [exclude](https://www.typescriptlang.org/tsconfig#exclude), and [files](https://www.typescriptlang.org/tsconfig#files) to specify which items will be considered as source code. I also understand that I can adjust the resolution of absolute imports with [baseUrl](https://www.typescriptlang.org/tsconfig#baseUrl), [paths](https://www.typescriptlang.org/tsconfig#paths), and [rootDir(s)](https://www.typescriptlang.org/tsconfig#rootDir)

Scope

I know that there are built-in options that allow me to adjust TypeScript compatibility with [JSON files](https://www.typescriptlang.org/tsconfig#resolveJsonModule), [pure JavaScript](https://www.typescriptlang.org/tsconfig#allowJs), [JSX format](https://www.typescriptlang.org/tsconfig#jsx), and [decorators](https://www.typescriptlang.org/tsconfig#experimentalDecorators)

I also understand that I can use some [plugins](https://www.typescriptlang.org/tsconfig#plugins) to extend supported code, with for example, GraphQL and SQL syntax

Compatibility

I know that I can create a base configuration and then use it to [extend](https://www.typescriptlang.org/tsconfig#extends) or [reference](https://www.typescriptlang.org/tsconfig#references) it in the newly created **tsconfig.json**

Reusability

# One to Rule Them All

There is one file that defines how strictly TypeScript will analyze your code. The **tsconfig.json** requires a proper setup and options for your project to be safely checked.

You will need to understand the core options and their default values to avoid making mistakes that may later require a lot of work to fix.

TS configuration

I know how to create a generic function for both **standard** functions and **lambdas**

I also know that inside files containing `<JSX />`, I cannot use generic lambdas

Generic function syntax

I know that I can use the same patterns as in templates to define the return type based on the argument types

I am aware that often when dealing with generic functions, I need to resort to using **any** and **as**

Return type

Often, you will create **standardized utility functions** that perform tasks like validating the schema or operating on more complex, nested structures.

These functions can typically process various types of input, but the result of the function will also vary **based on the type** of the provided data. You need to know how to type these kinds of functions. The knowledge and patterns from templates will be useful here as well.

Generic functions

I can create a basic class with TypeScript support for specifying the types of its methods and properties

Basic class

I can create an interface and use it to enforce its implementation in newly created classes

Implementing interface

I know how to define constructor types inside an interface and how to define their overloads

Constructor

I know that I can **extend** existing classes and even override the types of their existing methods and properties

I also understand how the **super** argument works

Inheritance and super methods

Working with classes in JavaScript used to be quite challenging until the `class` keyword was introduced in the ES6 specification. TypeScript further enhances the experience with this controversial part of JavaScript and provides safer code handling.

Classes work effectively **with interfaces**, allowing developers with experience in other object-oriented programming (OOP) languages to find familiar and for basic patterns.

Classes

I know how to add all the required TypeScript compilers to a selected bundler

For example, I know how to extend the webpack configuration to support TypeScript syntax within a project with JSX

TypeScript bundling

I know that for some libraries, I will need to install additional packages containing type definitions

Libs typing

I know that I need to adjust static code analysis tools to handle TypeScript syntax correctly

I know how to set up [ESLint](https://typescript-eslint.io/) rules so they will not report valid TypeScript syntax as errors

TypeScript vs static code analysis

When you want to create a new modern app, you will probably start with an **out-of-the-box tool** that provides basic configuration supporting TypeScript. Tools like [Vite](https://vitejs.dev/guide/features.html#typescript) are already prepared to use with TS code.

For apps created from scratch, you will be required to add a proper plugin to the bundler. You should also incorporate the necessary addons for tools like [ESLint](https://typescript-eslint.io/) to adjust their syntax for TypeScript.

Application setup

I know how to create a basic template type accepting **generic** type and creating type using passed type

I know how to make passed type option using default type

Basic template type

I know that I can contain template values using the **extends** keyword and a more strict type as the base

Constain template value

I know that I can limit the types passed inside template arguments **based on the previous** types – e.g., limiting the second argument to keys of the first one

Relation between arguments

I know that I can create conditional types using **extends** and **ternary operator**

I know this syntax is mostly useful inside template types

Conditional types

When creating more **reusable parts of your code**, the result types start to have a similar structure. To create **generic templates** of types, you can use a template system.

With this TypeScript feature, you will be able to create reusable types that will automatically adjust to the inputs and make your typing system **more flexible** in the future.

Templates

I can create enumerated types for both string and number values

Create own enum

I know that usage of enums is by some considered as **an antipattern**. I know that I can use immutable object created with **as const** as an alternative solution to enums

I know pros and cons of both approaches to enumerated values

Replace enums with as consts

TypeScript has a specific type called **Enum** to handle data types consisting of a set of named values

TypeScript supports number, string, and mixed types of enums

Enums

I know that I can specify the compatibility of the type system with different node environments using the [module](https://www.typescriptlang.org/tsconfig#module), [moduleResolution](https://www.typescriptlang.org/tsconfig#moduleResolution), and [lib](https://www.typescriptlang.org/tsconfig#lib) options

I'm aware that I can adjust the output JavaScript syntax format with the [target](https://www.typescriptlang.org/tsconfig#target) field

JavaScript standard compatibility

I know I can adjust the handling of JSX syntax within the [JSX](https://www.typescriptlang.org/tsconfig#jsx) option

I know that I can control what will be included in the final bundle and where the specific parts will be placed

I use [declaration](https://www.typescriptlang.org/tsconfig#declaration), [declarationDir](https://www.typescriptlang.org/tsconfig#declarationDir), and [emitDeclarationOnly](https://www.typescriptlang.org/tsconfig#emitDeclarationOnly) to handle types output. I use [out / outDir / outFile](https://www.typescriptlang.org/tsconfig#outDir) to manage JavaScript output

I'm aware that options like [isolatedModules](https://www.typescriptlang.org/tsconfig#isolatedModules) can impact the structure of the code's outcome

Bundling

When you are using TypeScript inside projects that create a standalone web application, you do not need to think much about the compilation process, as it is likely handled by some out-of-the-box tools (NextJS, CRA, etc.). However, when you are trying to create a **publishable** library that will be used in other apps, the bundling options are **crucial** to understand.

Running `tsc` locally will compile the closest project defined by a **tsconfig.json**. This tool can be used to compile simple TypeScript libraries, and the outcome will be determined by the configuration.

Other compilers also take into consideration the configuration that is set for the TypeScript compiler. **Webpack** and **Rollup** will use it to **transpile .ts(x)** files into their final form.

You will need to understand the most important options to have full control over the output. This is essential for **optimizations** and proper **compatibility**.

Bundling types

I know how to create a type predicate function

I know how to use it inside if statements and operations like **filter** on the array

Type predicate

A **type predicate** is a type assertion that checks if a variable has a specific property or set of properties. This allows TypeScript to narrowthe type of a variable based on the result of the function

You can create a function and mark it as a **type predicate** and use it in utility function and if statements to help TypeScript better understand the code

I know that I can use the **infer** keyword inside conditional types to declaratively introduce a new generic type variable.

I also know how to apply this mechanism to array items or function type elements.

Infer keyword

I know how to use the **in keyof** syntax to create a generic object type based on an existing object type while applying modifications using, for example, the `+` and `-` operators.

Mapping modifiers

I know that I can remap keys using the in `keyof ... as ...` syntax. I also know that I can use template literal types to apply transformations to the keys, such as adding prefixes or capitalizing them, and so on

Key remapping and template literal types

I know that I can disable the **distributivity** of union types by surrounding each side of the extends keyword with square brackets.

Distributive conditional types

When creating generic functionality, the complexity of the result type of the operation can increase. There are **a few techniques** that enable you to handle specific scenarios when the result type varies widely for different types of input.

Use these utilities to fully harness the **power of TypeScript**!

Advanced templates

I know that the **this** argument for methods of classes receives special treatment during the compilation process

I also understand that I do not need to explicitly define it when a method is declared inside a class

This is magic

I know that I can create a type guard that will handle code for a specific type of inherited class

This typeguard pattern

I know that TypeScript allows marking parameters and methods as public, private, and protected, but this is only enforced at the **type checking** level

I also know that I can still use the **#** prefix

Public, private and protected

I know how to handle when function needs an instance of specific class as and argument

I know how to declare properly that function accepts a class constructor

Instance of vs constructor signature

Classes in JavaScript, and consequently in TypeScript, continue to receive new features with each ES version. Some unique and exotic features can be applied to further enhance the typing system in this part of the codebase.

Advanced classes

Fundamentals

Intermediate

Advanced

TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale

TypeScript - Best practices and conventions

Type vs interface

Do not use

Function return types

Use tuples