DEV Community: Cyrille Tuzi

TypeScript strictly typed - Part 4: full static types

Cyrille Tuzi — Wed, 31 Jul 2024 12:36:50 +0000

In the previous part of this posts series, we discussed about safe nullability.

Now we will explain and solve the third and last problem of TypeScript default behavior: remains of dynamic typing.

We will cover:

Remains of dynamic typing
Actual equality checks
No implicit conversions in conditions
Conditions shorthand notation
No strings and numbers mix

Remains of dynamic typing

TypeScript is supposed to be a "static type checker", as opposed to JavaScript in which typing is deeply dynamic.

But in a previous part of this post series, we also explained that TypeScript is built as a superset of JavaScript.

So the problem is: some parts of JavaScript dynamic typing system remain in TypeScript. We are thus going to explain how to suppress these remaining behaviors to achieve full static typing.

Actual equality checks

ESLint: eqeqeq
Oxlint: eqeqeq

The best example of the problem is equality checks. In JavaScript, == is not exactly an equality check, but an equivalence check:

1 == "1"; // true

Despite the types being different, some conversion rules come into action so JavaScript is able to compare the values. It can lead to a lot of errors, because the rules details are difficult to remember, are sometimes quite weird, and are not exactly the same in all dynamic languages (like PHP for example).

These equivalence checks only makes sense in a dynamically typed language like JavaScript. From the moment we decide to work in TypeScript, only actual equality checks (type and value) should be used.

1 === "1"; // false

The eqeqeq lint rule enforces it.

People coming from languages like Java, C# or Rust should be particularly careful with this problem, as == in JavaScript or TypeScript does not mean the same as in these languages. In JavaScript and TypeScript, a third = is required to achieve the same behavior.

No implicit conversions in conditions

ESLint: @typescript-eslint/strict-boolean-expressions
Oxlint: typescript/strict-boolean-expressions

Think conditions are now safe? Unfortunately not, because conversions can be implicit:

let tax: number | undefined = 0;

if (tax) {
  console.log("Process payment");
}
if (!tax) {
  throw new Error();
}

The above example is equivalent to:

let tax: number | undefined = 0;

if (tax == true) {
  console.log("Process payment");
}
if (tax == false) {
  throw new Error();
}

As you can see, there were implicit ==, so conversions still happen: 0 is not equivalent to true, it is equivalent to false. So it will error despite tax being a valid value.

The strict-boolean-expressions lint rule disallows such implicit conditions, and enforces actual checks:

let tax: number | undefined = 0;

if (tax !== undefined) {
  console.log("Process payment");
}
if (tax === undefined) {
  throw new Error();
}

It may be one of the most tedious rule to follow for people used to quick conditions in JavaScript, but to put it into perspective, it is just the normal way to do things in other languages like Java, C# or Rust.

As shown in the configuration part, disabling allowNumber and allowString sub-options is important to avoid all errors.

The only exception allowed is for objects and arrays: these cases are safe because contrary to strings and numbers, they do not have falsy values. So the following is still OK:

let movie: Movie | undefined;
if (movie) {}
if (!movie) {}

Note: switch statements are already safe as they use === internally.

Conditions shorthand notation

ESLint: @typescript-eslint/prefer-nullish-coalescing (in stylistic-type-checked)
Oxlint: typescript/prefer-nullish-coalescing

The strict-boolean-expressions lint rule takes care that conditions checks are type safe, but there are other conditions syntaxes than if:

const movieRating = userRating || 5;

// Which is a shorter version of:
const movieRating = userRating == true ? userRating : 5;

If the user rated 0, 0 is equivalent to false, so rating will be 5 instead of 0.

It can be avoided with modern JavaScript:

const movieRating = userRating ?? 5;

// Which is a shorter version of:
const movieRating = userRating !== undefined && userRating !== null
  ? userRating
  : 5;

It can be enforced by the prefer-nullish-coalescing lint rule.

Note that ?? should not be used everywhere: || is still relevant when working with booleans.

No strings and numbers mix

ESLint:
- prefer-template
- @typescript-eslint/restrict-plus-operands (in recommended-type-checked)
- @typescript-eslint/restrict-template-expressions (in recommended-type-checked)
Oxlint:
- prefer-template
- typescript/restrict-plus-operands
- typescript/restrict-template-expressions (enabled by default)

In JavaScript, the + operator can be used both for mathematical addition of numbers, or strings concatenation. It leads to error.

"There is " + 3 + 1 + "Matrix movies"; // 31
"There is " + (3 + 1) + "Matrix movies"; // 4

The + operator should be reserved for mathematical addition. Or at least, it should be used only with data of the same type, which the restrict-plus-operands lint rule enforces.

Template strings from modern JavaScript should be used for string concatenation, which the prefer-template lint rule enforces:

const movie = `Everything everywhere all at once`;
`${movie} is the best movie!`;

Conversely, only strings should be used in template strings, which the restrict-template-expressions lint rule enforces.

If mixing types is what is actually wanted, conversions should be explicit:

const total = 3;
`There is ${total.toFixed()} Matrix movies`;

Note that template strings can be nested:

const total = 3;
`There is ${total.toFixed()} Matrix movie${total > 1 ? "s" : ""}`;

Conclusion

This is the end of this posts series. You can follow my account (button on top right of this page) to know when other posts about TypeScript or other topics like Angular are published.

You want to contact me? Instructions are available in the summary.

TypeScript strictly typed - Part 3: safe nullability

Cyrille Tuzi — Wed, 17 Jul 2024 12:39:35 +0000

In the previous part of this posts series, we discussed about full coverage typing.

Now we will explain and solve the second problem of TypeScript default behavior: unsafe nullability.

We will cover:

Required nullability checks
Required properties initialization
Objects vs records
Required indexes checks
Exact properties types
Handling inexact libraries
Evil !

Required nullability checks

TypeScript: strictNullChecks (in strict)
ESLint: @typescript-eslint/prefer-optional-chain (in stylistic-type-checked)
Oxlint: typescript/prefer-optional-chain

In JavaScript, no matter what is the type of a variable, it can always contain null or undefined. It leads to errors:

/* Without strict mode */

let movie: string = "The Matrix";
// OK
movie = null;
// Runtime error
movie.toUpperCase();

// Runtime error if the id does not exist
document.querySelector("#wrong-id")
  .addEventListener("click", () => {});

With strictNullChecks, the second most important TypeScript compiler option, a type cannot be null or undefined unless it is explicitly authorized, and TypeScript will enforce checks for values which can be nullish.

/* With strict mode */

let movie: string = "The Matrix";
// Compilation error
movie = null;

let nullableMovie: string | null = "The Matrix";
// OK
nullableMovie = null;

// Compilation error
document.querySelector("#wrong-id")
  .addEventListener("click", () => {});
// OK
document.querySelector("#wrong-id")
  ?.addEventListener("click", () => {});

As in the above example, modern JavaScript, with the optional chaining operator, will help a lot to handle nullability without introducing more conditions and complexity. It can be enforced by the prefer-optional-chain lint rule.

It also happens a lot with objects, for which some properties can be optional and/or undefined.

/* With strict mode */

interface Movie {
  // Required property
  title: string;
  // Optional property
  summary?: string;
  // Required property which can be undefined
  summary: string | undefined;
  // Optional property which can be undefined
  summary?: string | undefined;
}

We will discuss the difference between the last 3 forms below.

Required properties initialization

TypeScript: strictPropertyInitialization (in strict)

strictPropertyInitialization is just a variant of strictNullChecks for class properties. Let us look at this example:

/* Without strict mode */

class Movie {
  title: string;

  getUpperCasedTitle() {
    return this.title.toUpperCase();
  }
}

const movie = new Movie();
// Runtime error because `title` is undefined
movie.getUpperCasedTitle();

If a class property is not initialized (either in its declaration or in the constructor), then it can be undefined.

/* With strict mode */

class Movie {
  // Compilation error
  titleNotInitialized: string;
  // OK
  titleInitializedDirectly = "The Matrix";
  titleInitializedInConstructor: string;
  titleOptional: string | undefined;

  constructor(title: string): void {
    this.titleInitializedInConstructor = title;
  }
}

It can get complicated if initialization involves some asynchronous actions, as a class constructor cannot be asynchronous. This pattern can be used:

class Movie {
  title: string;

  // Do not allow direct instantiation
  // to enforce the use of `getInstance()`
  private constructor(title: string) {
    this.title = title;
  }

  static async getInstance(): Movie {
    const title = await fetchTitle();
    return new this(title);
  }
}

const movie = await Movie.getInstance();

Objects vs records

TypeScript: noPropertyAccessFromIndexSignature

Technically noPropertyAccessFromIndexSignature does not impact type correctness, but it is closely related to the next option, noUncheckedIndexedAccess, so we will explain it first.

Most objects have a defined interface with known properties. But sometimes an object with dynamic properties is needed.

interface CssValue {
  // It means the object can have any property
  // with a string index and a string value
  [key: string]: string;
}

const css: CssValue = {
  color: "blue",
  border: "1px solid red",
};

Note that the code above is a legacy syntax. TypeScript introduced a proper concept for this case called Record, with a simpler and recommended syntax:

type CssValue = Record<string, string>;

const css: CssValue = {
  color: "blue",
  border: "1px solid red",
};

As it is indeed a different concept, noPropertyAccessFromIndexSignature enforces a special syntax to access such dynamic properties:

// Compilation error with `noPropertyAccessFromIndexSignature`
css.color;
// OK
css["color"];

Why a specific syntax? To be sure to take into account that color may not exist, as dynamic properties allow any property.

Note that in most cases, records would be better expressed as maps, which is a real proper concept in JavaScript:

type CssValue = Map<string, string>;

const css: CssValue = new Map([
  ["color", "blue"],
  ["border", "1px solid red"],
]);

css.get("color"); // string | undefined!

Required indexes checks

TypeScript: noUncheckedIndexedAccess
ESLint: @typescript-eslint/prefer-for-of (in stylistic)
Oxlint: typescript/prefer-for-of

Let us continue to talk about records.

/* In default mode */
type CssValue = Record<string, string>;

const css: CssValue = {
  color: "blue",
};
css["color"]; // string
css["border"]; // string

Spotted the issue? The last line is obviously erroneous.

noUncheckedIndexedAccess will do the job correctly:

/* With `noUncheckedIndexedAccess` */
type CssValue = Record<string, string>;

const css: CssValue = {
  color: "blue",
};
css["color"]; // string | undefined
css["border"]; // string | undefined

Now the last line is correct.

But notice that color is now considered to potentially be undefined too, which will require additional checks.

Why? Because the css variable is typed as Record<string, string>, which does not ensure the existence of any specific property. The explicit generic record type somewhat overrides the more specific type which TypeScript could infer from the concrete value.

One cannot just delete the explicit type: it would mean that the object is not checked at all and could contain errors (for example, having boolean values).

But there is a solution:

type CssValue = Record<string, string>;

const css = {
  color: "blue",
} satisfies CssValue;

css.color; // string
css.border; // Compilation error

And notice that as TypeScript is now sure there is a color property, it also allows us to come back to the classic dot syntax!

As a reminder, all of this would have been avoided with a Map instead of a record.

noUncheckedIndexedAccess also applies to array indexes:

const movies: string[] = [`The Matrix`];

/* In default mode */
movies[3]; // string
/* With `noUncheckedIndexedAccess` */
movies[3]; // string | undefined

It can causes issues in some places where TypeScript cannot infer information at compilation time, because it depends on concrete values at runtime:

/* With `noUncheckedIndexedAccess` */
for (let i = 0; i < movies.length; i++) {
  movies[i]; // string | undefined
}

But it is easily avoided by writing modern JavaScript, which can be enforced by the prefer-for-of lint rule:

const movies: string[] = [`The Matrix`];

for (const movie of movies) {
  movie; // string
}

Need the index?

const movies: string[] = [`The Matrix`];

for (const [index, movie] of movies.entries()) {
  movie; // string
}

Exact properties types

TypeScript: exactOptionalPropertyTypes

Most people think the below 2 ways to define a property are equivalent:

interface Movie {
  title?: string;
  title: string | undefined;
}

In TypeScript default mode, they are equivalent. But in reality, at JavaScript runtime, they are not.

title?: string; means that the property title may not exist in the object. But if it exists, it will always be a string.

title: string | undefined; means that the property title will always exist in the object. But its value may be a string or undefined.

In some scenarios, it gives different results:

class Movie {
  optionalStringTitle?: string;
  requiredStringOrUndefinedTitle: string | undefined;
}

const movie: Movie = {
  requiredStringOrUndefinedTitle: undefined,
};

// false
if ("optionalStringTitle" in movie) {}
// true, but the value is `undefined`
if ("requiredStringOrUndefinedTitle" in movie) {}

exactOptionalPropertyTypes enforces to manage these differences correctly, so it reflects the actual runtime behavior.

When enabled, it also means a third scenario is possible:

interface Movie {
  title?: string;
  title: string | undefined;
  title?: string | undefined;
}

Question is: which one to choose?

Whenever the data is a parameter of something (functions mainly), the third form should be chosen to allow both possibilities.

Why? Because the function consumer may be forced to use one form, and they should be able to use the function without additional transformations:

interface MovieOptions {
  speed?: number | undefined;
  subtitles?: boolean | undefined;
}

function watchMovie(options: MovieOptions): void {}

/* All the code below should be OK */

watchMovie({
  // No `speed` property
  subtitles: true,
});

// May be `undefined`
const subtitles = configFromPreviousCode?.subtitles;
watchMovie({
  subtitles,
});

Otherwise, it will be more complicated to manage some scenarios. Let us imagine a common scenario: library code which does not allow undefined values.

/* Some library */
interface MovieOptions {
  speed?: number;
  subtitles?: boolean;
}

function watchMovie(options: MovieOptions): void {}

/* User code */
const subtitles = configFromPreviousCode?.subtitles;

watchMovie({
  // Compilation error with `exactOptionalPropertyTypes`
  subtitles,
  // OK
  ...(subtitles ? { subtitles } : {}),
});

So it is particularly important from frameworks and libraries author to be aware of this issue.

Conversely, when owned data is described, it should be described as exactly as possible. For example, when getting JSON data from a HTTP request, some properties will be optional, but it is unlikely that an object contains a property with undefined as a value.

interface MovieFromJSON {
  speed?: number;
  subtitles?: boolean;
}

Handling inexact libraries

TypeScript: skipLibCheck

exactOptionalPropertyTypes and noUncheckedIndexedAccess seem to fix some TypeScript incorrectness. So one could ask why it is not included in strict mode or in strictNullChecks.

From what I know, it is mostly for backward compatibility with existing libraries. Indeed, one will probably meet some library code causing issues here and there, especially with exactOptionalPropertyTypes.

So should a project sacrifice some strict options and thus correctness because it includes a non-strict-enough library?

Hopefully not. Apart from creating an issue and a Pull Request to fix it in the library repository, the skipLibCheck compiler option can also be enabled.

It will skip type checks inside library code (meaning code in node_modules) and just type check the project own code.

Most frameworks already enable this option by default for performance (less checks = faster compilation), and it is a recommended option in the official TypeScript documentation.

Evil !

ESLint: @typescript-eslint/no-non-null-assertion (in strict)
Oxlint: typescript/no-non-null-assertion

In TypeScript, the ! operator tells the compiler to trust us about the fact that a data is not null or undefined, without any checks.

// Runtime error if undefined
unsureMovie!.watch();

It is basically destroying all the nullability safety we talked above. So, of course, it should be prohibited by the no-non-null-assertion lint rule.

In most cases, undefined values must be checked with the ? operator:

unsureMovie?.watch();

Next part

In the next part of this posts series, we will explain and solve the third and last problem of TypeScript default behavior: remains of dynamic typing.

You want to contact me? Instructions are available in the summary.

TypeScript strictly typed - Part 2: full coverage typing

Cyrille Tuzi — Wed, 12 Jun 2024 16:53:10 +0000

In the previous part of this posts series, we discussed about how and when to configure a TypeScript project. Now we will explain and solve the first problem of TypeScript default behavior: from partial to full coverage typing.

We will cover:

What is really TypeScript?
How typing works in TypeScript?
Required missing types
Ban any any
The unknown unknown type
Required errors checks
Who is this?
Should we add explicit types everywhere?
Required objects and arrays types
Required return types
Dangerous assertions
Do not use any library
A better TypeScript lib

What is really TypeScript?

This topic requires to understand TypeScript correctly.

The official TypeScript home page defines it as "a strongly typed programming language that builds on JavaScript".

Everyone knows about the first part of the definition. Fewer are fully aware of the second part, "that builds on JavaScript", and what it means exactly.

It means that TypeScript is a superset of JavaScript. Told differently: valid JavaScript should be valid TypeScript.

Just change example.js to example.ts and it should be OK! (If by doing so, one gets errors, it would only be because they were doing bad things which were undetected in JavaScript, but never because of a TypeScript syntax problem.)

It was an important decision in TypeScript design, because it is one of the main reasons of its success.

Indeed, if one already knows how to program with JavaScript, they already know how to program with TypeScript. Sure it will be basic TypeScript, but one does not have to learn a whole new language.

How typing works in TypeScript?

But this has a drawback: TypeScript is only partially typed by default.

Let us take a really basic example, which is valid JavaScript (and thus valid TypeScript):

function chocolate(quantity, organic = true) {}

Given that organic parameter has a default value, TypeScript is able to automatically infer that its type is boolean.

But TypeScript is not a seer: it cannot infer the type of quantity parameter.

So with explicit types and without strict mode, the above example is equivalent to this:

function chocolate(quantity: any, organic: boolean = true): void {}

It means that without strict mode, only a portion of the code is really typed. Correctness of what is done with organic variable will be checked, but not what is done with quantity:

function chocolate(quantity: any, organic: boolean = true): void {
  // Compilation OK, but runtime error if `quantity` is a number
  quantity.toUpperCase();
  // Compilation error
  organic.toUpperCase();
}

Required missing types

TypeScript: noImplicitAny (in strict)

To fix this behavior, noImplicitAny is the most important TypeScript compiler option. It is included in strict mode.

// Compilation error in strict mode
function chocolate(quantity, organic = true) {}

It enforces explicit types when TypeScript cannot infer automatically:

// OK
function chocolate(quantity: number, organic = true) {}

Note that noImplicitAny enforces explicit types only when inference is not possible. So it is not required to add explicit types everywhere. But should we? We will discuss that below.

Ban any `any`

ESLint: @typescript-eslint/no-explicit-any (in recommended)
Oxlint: typescript/no-explicit-any

noImplicitAny is not strict enough yet. TypeScript still allows this code:

function watch(movie: any): void {
  // Runtime error if `movie` is not a string
  movie.toUpperCase();
}

any means it can be anything, so TypeScript will let us do anything from that point. One could consider that movie.toUpperCase() is not really TypeScript anymore, but just totally unchecked JavaScript.

So explicit any must be disallowed completely via the linter no-explicit-any rule.

The unknown `unknown` type

But what to do when one really does not know a data type? The right type to use is unknown.

function watch(movie: unknown): void {
  // Compilation error
  movie.toUpperCase();

  if (typeof movie === "string") {
    // OK
    movie.toUpperCase();
  }
}

The difference here is that unknown means what it means: the data type is unknown, so TypeScript will not let us do anything, except if we check the type by ourself.

But note that except for very few special cases, data types are usually known. What happens more frequently is that the type can be variable: it is called generics.

interface ApiData<T> {
  error?: string;
  data: T;
}

function fetchData<T>(): ApiData<T> {}

fetchData<Movie>();
fetchData<TVSeries>();

Another reason one could be tempted to use any or unknown is when the data structure is too complicated to describe.

Types can serve here as a design warning: if a structure is too complicated to describe as a type, it should probably be simplified, or maybe the wrong concept is used (an object instead of a Map for example).

Required errors checks

TypeScript: useUnknownInCatchVariables (in strict)
ESLint: @typescript-eslint/use-unknown-in-catch-callback-variable (in strict-type-checked)
Oxlint: typescript/use-unknown-in-catch-callback-variable

useUnknownInCatchVariables exists because TypeScript cannot be sure at compilation time what will be the type of errors in catch blocks.

/* Without strict mode */
try {
  someAction();
} catch (error) { // `any` type
  // Runtime error if not an `Error`
  error.message;
}

/* With strict mode */
try {
  someAction();
} catch (error) { // `unknown` type
  // Compilation error
  error.message;

  // OK
  if (error instanceof Error) {
    error.message;
  }
}

The same issue happens in the asynchronous version in Promises, but is not handled by the former option.

The linter use-unknown-in-catch-callback-variable rule enforces to do it:

fetch("/api").catch((error: unknown) => {});

Note that it is an exceptional case. In normal situations, typing callback functions parameters should not be done like this: it is the responsibility of the outer function to type the callback function, including its parameters.

Who is `this`?

TypeScript: noImplicitThis (in strict)
ESLint: prefer-arrow-callback
Oxlint: missing rule (progress tracked here)

noImplicitThis is also about avoiding any, for this.

class Movie {

  title = "The Matrix";

  displayTitle(): void {

    window.setTimeout(function () {
      // Runtime error without strict mode,
      // because `this` has changed and is no more the class instance
      this.title;
    }, 3000);

  }

}

But note that it happens because the code above is not using correct and modern JavaScript. Arrow functions should be used to keep the this context.

class Movie {

  title = "The Matrix";

  displayTitle(): void {

    window.setTimeout(() => {
      // OK, `this` is still the class instance
      this.title;
    }, 3000);

  }

}

Arrow syntax can be enforced by the linter prefer-arrow-callback rule.

Should we add explicit types everywhere?

ESLint: @typescript-eslint/no-inferrable-types (in stylistic)
Oxlint: typescript/no-inferrable-types

For variables assigned to primitive static values, like strings, numbers and booleans, it is superfluous and just a preference. The preset of TypeScript ESLint enable the no-inferrable-types rule, which disallows explicit types in this case, to keep the code concise.

But developers from Java, C# or Rust, who are accustomed to explicit types nearly everywhere, can make the choice to do the same in TypeScript and to disable this rule.

Required objects and arrays types

ESLint: missing rule
Oxlint: missing rule

On the other hand, when it is a more complex structure, like arrays and objects, it is better to use explicit types. TypeScript can always infer a type when there is a value, but the inference happens based on what the code does. So we presuppose the code is doing things right.

// Bad
const inferred = ["hello", 81];
// Good: classic array, not mixing types
const explicitArray: string[] = ["hello", "world"];
// Good: tuple (although rarely the best solution)
const explicitTuple: [string, number] = ["hello", 81];

// Bad
const movieWithATypo = {
  totle: "Everything everywhere all at once",
};
// Good
interface Movie {
  title: string;
}
const checkedMovie: Movie = {
  title: "Everything everywhere all at once",
};

Required return types

ESLint: @typescript-eslint/explicit-function-return-type
Oxlint: typescript/explicit-function-return-type

Same goes with functions: TypeScript is always able to infer the return type, but it does so based on what the function does. If the function is modified, the return type will continue to be inferred, but the modifications may have change this type by error.

The linter explicit-function-return-type rule enforces to explicitly type the functions returns.

It is also considered a good practice because the return type is part of the core and minimal documentation one should include for every function.

Dangerous assertions

ESLint: @typescript-eslint/no-unsafe-type-assertion
Oxlint: typescript/no-unsafe-type-assertion

Casting with as tells the compiler to trust us about a type, without any check. It should be prohibited. For example:

const input = document.querySelector("#some-input") as HTMLInputElement;

// Runtime error if it is not really an input
// or if it does not exist
input.value;

// OK
if (input instanceof HTMLInputElement) {
  input.value;
}

The worst thing which can be done is this:

movie as unknown as TVSeries;

TypeScript sometimes suggests to do that in some scenarios, and it is a terrible suggestion. Like any, it is basically bypassing all type checks and going back to blind JavaScript.

There are justified exceptions. One is when implementing a HTTP client: TypeScript cannot know the type of the JSON sent by the server, so we have to tell it. Still, we are responsible that the client forced type matches the server model.

Another one is when fixing an "any" coming from a library: casting can serve here to retype correctly.

Type predicates is just a variant of type assertions for functions returns. The most common case is when filtering an array:

/* With TypeScript <= 5.4 */
const movies: (string | undefined)[] = [];

movies
  .filter((movie) => movie !== undefined)
  .map((movie) => {
    // string | undefined
    // because TypeScript is not capable to narrow the type
    // based on what the code do in `filter`
    movie;
  });

movies
  .filter((movie): movie is string => movie !== undefined)
  .map((movie) => {
    // string
    movie;
  });

Nice, but the compiler trusts us. If the check does not match the type predicate, errors may happen.

While this feature can be useful and relevant in some cases, it should be double checked when used.

Note that I took the filter example because it is the most frequent one. But now:

/* With TypeScript >= 5.5 */
const movies: (string | undefined)[] = [];

movies
  .filter((movie) => movie !== undefined)
  .map((movie) => {
    // string
    movie;
  });

Be sure when updating to TypeScript 5.5 to delete movie is string, because the behavior is not exactly the same. Explicit movie is string still means the compiler blindly trusts us. But the new implicit behavior is inferred from the actual code in filter, so now the type predicate is really checked!

It also means it becomes an exception of the linter explicit-function-return-type rule: in such scenarios, the return type should not be explicit.

Do not use any library

ESLint (in recommended-type-checked):
Oxlint:

Now our code has full coverage typing. But in a real world project, frameworks and libraries are also included. What if they introduced some any?

Some other linter no-unsafe-xxx rules catch when something typed as any is used.

But as a prior step, one should audit libraries carefully before adding them in a project. Accumulating not reliable enough libraries is another major recurring problems in JavaScript projects.

It can be made into a criterion of choice: one can go see the tsconfig.json and the lint configuration in the library GitHub repository to check if it is typed in a strict way.

One should not be too demanding though: currently there are probably no libraries following all the recommendations from this posts series. At the current state of the TypeScript ecosystem, having the strict mode and the no-explicit-any rule is already a lot.

A better TypeScript lib

There is one hole left in our typing coverage: what about the types of native JavaScript functions and classes?

Few knows it, but if our code editor knows what is the type expected by JSON.parse() for example, it is because TypeScript includes definitions for every JavaScript native API, in what is called "libs".

In Visual Studio Code, if we cmd/ctrl click on parse(), we arrive in a file called lib.es5.d.ts, with definitions for a lot of JavaScript functions. And in this example, we see any as the return type.

Those any have a historical reason (for example, unknown did not exist in the very first versions of TypeScript). And correcting that now would break a lot of existing projects, so it is unlikely to happen.

But even fewer knows these definitions can be overridden. It is what does the amazing better-typescript-lib by uhyo. And what is really magical is that one just needs to:

npm install better-typescript-lib --save-dev

and we are done! Now JavaScript native APIs will be typed correctly with no more any.

To be transparent: I discovered this wonder very recently. My first usages of it were successful, but I have little perspective on it yet. But it is not a big risk: in worst case scenario, just uninstall the library and that is it.

Note that the use-unknown-in-catch-callback-variable lint rule becomes useless with this tool.

Next part

I hope you enjoyed the meta jokes.

In the next part of this posts series, we will explain and solve the second problem of TypeScript default behavior: nullability.

You want to contact me? Instructions are available in the summary.

TypeScript strictly typed - Part 1: configuring a project

Cyrille Tuzi — Wed, 12 Jun 2024 16:50:22 +0000

After the introduction of this posts series, we are going to the topic's technical core. First, we will talk about configuration, and why it is very important to do it at the very beginning of a project.

We will cover:

When to enable strict options?
Frameworks status
Full configuration (the hard way)
Automatic configuration (the easy way)

When to enable strict options?

I cannot insist more on the fact that strict options must be enabled at the very beginning of any project. Doing so is an easy and straightforward process: one just has to gradually type correctly when coding.

But enabling strict options in an on-going project is a completely different matter: even if TypeScript default mode is capable of inferring types in the majority of cases, the remaining untyped places are a proportion of the codebase. So the more code, the more places to fix, and it requires a clear understanding of what each code is doing.

It is one of the main recurring big errors I have seen in all the companies I have helped over the last decade as a TypeScript expert. Recovering from it is good but really time consuming and painful.

So be sure to always check a new project is in strict mode before to start coding.

Frameworks status

TypeScript strict mode is enabled automatically when generating a project with the last versions of:

TypeScript: tsc --init
Angular: npm init @angular@latest
React App: npx create-react-app --template typescript
Next.js: npx create-next-app@latest
Vue: npm create vue@latest, then choosing TypeScript
Deno: by default

Note it has not always been the case with older versions of these frameworks.

Full configuration (the hard way)

We will see in the next parts that the "strict" mode is not enough. Other TypeScript compiler options must be enabled, as well as some lint rules.

A complete configuration would look like this:

TypeScript compiler options

For TypeScript, in tsconfig.json:

{
  compilerOptions: {
    strict: true,
    exactOptionalPropertyTypes: true,
    noPropertyAccessFromIndexSignature: true,
    noUncheckedIndexedAccess: true
  }
}

Note that strict is now enabled by default in TypeScript >= 6.

ESLint

For ESLint + TypeScript ESLint, with the new flat config eslint.config.js:

export default defineConfig(
  eslint.configs.recommended,
  tseslint.configs.strictTypeChecked,
  tseslint.configs.stylisticTypeChecked,
  {
    languageOptions: {
      parserOptions: {
        project: true,
      },
    },
    rules: {
      "eqeqeq": "error",
      "prefer-arrow-callback": "error",
      "prefer-template": "error",
      "@typescript-eslint/explicit-function-return-type": "error",
      "@typescript-eslint/no-explicit-any": "error",
      "@typescript-eslint/no-non-null-assertion": "error",
      "@typescript-eslint/no-unsafe-argument": "error",
      "@typescript-eslint/no-unsafe-assignment": "error",
      "@typescript-eslint/no-unsafe-call": "error",
      "@typescript-eslint/no-unsafe-member-access": "error",
      "@typescript-eslint/no-unsafe-return": "error",
      "@typescript-eslint/no-unsafe-type-assertion": "error",
      "@typescript-eslint/prefer-for-of": "error",
      "@typescript-eslint/prefer-nullish-coalescing": "error",
      "@typescript-eslint/prefer-optional-chain": "error",
      "@typescript-eslint/restrict-plus-operands": ["error", {
        "allowAny": false,
        "allowBoolean": false,
        "allowNullish": false,
        "allowNumberAndString": false,
        "allowRegExp": false,
      }],
      "@typescript-eslint/restrict-template-expressions": "error",
      "@typescript-eslint/strict-boolean-expressions": ["error", {
        "allowNumber": false,
        "allowString": false,
      }],
      "@typescript-eslint/use-unknown-in-catch-callback-variable": "error",
    },
});

Important: many of these rules require typed linting, which is configured above with project: true.

Oxlint

For Oxlint, in .oxlintrc.json:

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "options": {
    "typeAware": true
  },
  "rules": {
    "eqeqeq": "deny",
    "prefer-template": "deny",
    "typescript/explicit-function-return-type": "deny",
    "typescript/no-explicit-any": "deny",
    "typescript/no-non-null-assertion": "deny",
    "typescript/no-unsafe-argument": "deny",
    "typescript/no-unsafe-assignment": "deny",
    "typescript/no-unsafe-call": "deny",
    "typescript/no-unsafe-member-access": "deny",
    "typescript/no-unsafe-return": "deny",
    "typescript/no-unsafe-type-assertion": "deny",
    "typescript/prefer-for-of": "deny",
    "typescript/prefer-nullish-coalescing": "deny",
    "typescript/prefer-optional-chain": "deny",
    "typescript/restrict-plus-operands": [
      "deny",
      {
        "allowAny": false,
        "allowBoolean": false,
        "allowNullish": false,
        "allowNumberAndString": false,
        "allowRegExp": false,
      }
    ],
    "typescript/restrict-template-expressions": "deny",
    "typescript/strict-boolean-expressions": [
      "deny",
      {
        "allowNumber": false,
        "allowString": false,
      }
    ],
    "typescript/use-unknown-in-catch-callback-variable": "deny"
  }
}

Important: many of these rules require type-aware linting, which require additional setup.

Also, while Oxlint puts forward as an advantage the fact that no configuration is required by default, be careful that nearly none of the rules presented in these posts are enabled by default in Oxlint, so you do need a configuration file to achieve proper strict typing.

Biome

Biome initially planned feature parity with ESLint. Unfortunately, this goal has been abandoned. It means that a lot of the lint rules required to enforce strong, static and complete typing are missing in Biome.

As a consequence, for a project where strict typing is a goal, Biome is probably not the adequate choice. If one is looking for an alternative to ESLint and an equivalent of Biome, Oxlint mentioned above seems the new way to go.

Deno

For Deno, in deno.json:

{
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "useUnknownInCatchVariables": true
  },
  "lint": {
    "rules": {
      "tags": [
        "recommended"
      ],
      "include": [
        "eqeqeq",
        "explicit-function-return-type",
        "no-non-null-assertion"
      ]
    }
  }
}

Notes

Note that these configuration examples only include options and rules related to this posts series topic. Other options and rules may be added to enforce other TypeScript good practices not related to strict typing.

For all tools, be careful if a configuration extends another one. It could mean that even if a preset like strict is enabled, one of the individual option included in the preset is disabled in the parent configuration. So in this case, all options should be enabled individually.

Automatic configuration (the easy way)

Totally optional, but if one does not want to lose time to remember and configure all these options manually, one can run this command:

npx typescript-strictly-typed@latest

It is a tool I published to automatically add all the strict options in a TypeScript project.

Next part

In the next part of this posts series, we will explain and solve the first problem of TypeScript default behavior: from partial to full coverage typing.

You want to contact me? Instructions are available in the summary.

TypeScript strictly typed - Intro: reliability and productivity

Cyrille Tuzi — Wed, 12 Jun 2024 16:48:13 +0000

Before going to the technical core of this posts series, we said in the summary that by default TypeScript:

only partially enforces typing
does not handle nullability
retains some JavaScript's dynamic typing

We will explain these 3 problems and their solution in the next parts, but first, why is it important to solve them? Developers coming from Java, C# or Rust may not need to be convinced, and could skip this introduction.

We will cover:

TypeScript true promise
Reliability: bugs reduction
Productivity: easier and faster debug
Productivity: better autocompletion
Productivity: less tests to write
Scalability: safer refactoring
Design: better and simpler code
Put into perspective

TypeScript true promise

Having a code as correct as possible is not about being picky or about wanting a pretty code. It has very important and concrete consequences for a company.

Imagine one finds a magic box which can guess the lottery numbers. They just press the obvious big button on it and it guesses 3 out of 6 lottery numbers.

Now they turn the box upside down and press the little and barely visible secret button with "strict" written on it. Now the box guesses 5 of the 6 lottery numbers. But wait! There is also a super secret button with "strict + lint" written on it. Now the box guesses all the 6 lottery numbers.

Using TypeScript with its default behavior is basically the same as using the magic box without the secret buttons.

So answering why enforcing static, strong and complete typing is important is the same as answering why TypeScript is important. Once it is clear, it is just common sense to use TypeScript to its maximum potential.

Reliability: bugs reduction

It is the most obvious benefit:

JavaScript: 0% code verified, 100% risk of bugs
TypeScript without strict mode: ~50% code verified, 50% risk of bugs
TypeScript with strict mode: ~75% code verified, 25% risk of bugs
TypeScript strictly typed: ~100% code verified, 0% risk of bugs

To be clear:

percentages are a rough estimate from my experience, not exact science
0% risk of bugs = 0% risk of bugs which are handled by strong and static types, but of course there are other types of bugs which are still possible

Put in a real world context, where front-end teams are often new small teams, the maintenance costs are very important. If a team is made up of only 3 people, and 2 of them use all of their time to fix bugs, it means there is only one person left to add new product features.

Productivity: easier and faster debug

To check the code, TypeScript introduces a compilation step, like in other typed languages like Java, C# or Rust. And in TypeScript, compilation is happening in "watch" mode, while one is coding.

It is a totally different experience when it comes to debugging. Let us take a very basic example:

document.querySelector('#missing-id').textContent = "The Matrix";

With TypeScript strictly typed, the error is shown directly and immediately as one is coding (via the editor or via the compilation logs). There may even be a suggestion about how to fix the issue. It takes a few seconds.

Now going back to the raw JavaScript experience: everything seems OK in the editor. One has to launch a development server, go in the browser and open the console. Yet it is not enough: the console logs may be totally OK at this point. One has to reproduce the steps to trigger the scenario where the faulty code is called.

We are now talking about minutes of debugging, which can extend to hours.

And now imagine the faulty code is called in a scenario which does not happen often or which happens only under specific conditions. So it goes totally unnoticed while developing in local environment, and a bug is pushed to production.

Productivity: better autocompletion

If TypeScript is able to check all the code because everything is correctly typed, it also means the editor can help with autocompletion everywhere.

Once one goes back to any, the editor becomes blind, and cannot assist the developer anymore.

Interesting fact: if editor autocompletion in JavaScript is far better than some years ago, it is because it is now handled by TypeScript, even for pure JavaScript files!

So in some sense, like it or not, everyone is doing TypeScript today, and it is just a waste to not go for its full potential.

Productivity: less tests to write

If one is talking about testing strategies, but TypeScript is not in a strictly typed configuration, priorities may have to be reconsidered.

A very common and indicative case are unit tests checking unexpected undefined values: with TypeScript strictly typed, it cannot happen at all, so it does not need to be tested!

Everyone who has already written tests in a front-end project knows how time consuming it is. Also, the more tests = the more time the continuous integration tools (like GitHub Actions or else) take. And as these tools are not free, the more it costs to the company.

Scalability: safer refactoring

For the same reasons as for bugs, refactoring is a lot easier when in TypeScript strictly typed, because if one breaks something while refactoring, compilation will see it and notify it right away.

The accumulation of technical debt being one of the other major problems of most projects, being able to easily evolve is essential.

Design: better and simpler code

This benefit is rarely evoked, but I realized with experience that TypeScript is also a good indicator when designing code.

Too difficult to express the type of a variable? One may have chosen the wrong data structure, or a too nested one which would be easier to work with if it was flattened.

Too difficult to express the signature of a function? It may do too much things and not respect the single responsibility principle, or it may try to abstract too much.

Put into perspective

While the options names like "strict", which we will discuss in the next parts, may suggest it is an additional effort to do, it is not: enabling all the strict options we will discuss is just putting JavaScript at an equivalent level than the basic and default mode of the other typed languages like Java, C# or Rust.

One could say that it is TypeScript default mode which is a "loose" mode, while "strict" mode is just the normal mode if one wants to use strong and static types, which is what TypeScript is for in the first place.

Next part

In the next part of this posts series, we will explain how to configure a project to guarantee strict typing, and especially when it is important to do it.

You want to contact me? Instructions are available in the summary.

TypeScript strictly typed: the true promise of TypeScript

Cyrille Tuzi — Wed, 12 Jun 2024 16:45:52 +0000

The problem

Over the last decade, as a JavaScript expert, I helped companies of all kinds and sizes. Over time, I detected a series of some recurring major problems in nearly all projects.

One of them is a lack of typing, resulting in a lack of reliability and an exponential decline in productivity.

Yet, all these projects were coded in TypeScript. Should not it guarantee typing like in Java, C# or Rust?

Short answer: no, because by default TypeScript:

only partially enforces typing
does not handle nullability
retains some JavaScript's dynamic typing

These problems can be solved with adequate configuration and the resulting good practices. But for that, even strict mode, if one knows about it, is not enough.

This posts series claims to be a reference about a strong, static and complete typing in TypeScript, and I will try to keep it up to date.

Target audience

This posts series is intended for developers who already know TypeScript and who:

do not know about strict mode
do know about strict mode but think it is enough to guarantee sufficient typing
know languages like Java, C# or Rust and want a similar typing level in TypeScript
want to increase reliability of their code and reduce the risk of bugs
want to increase productivity

This posts series is not intended for people who:

do not like TypeScript and already have a definitive opinion about it

Changelog

2026/04/03: added a note about strict being enabled by default in TypeScript >= 6
2026/02/26: added Oxlint rules and configuration instead
2026/02/26: removed Biome rules and configuration, and added a note about Biome not being the most adequate choice when strict typing is a goal, as too many important lint rules are missing
2026/02/26: updated ESLint configuration example to match the latest updates, and removed ESLint legacy configuration example as it is not supported anymore by the latest ESLint version
2024/11/18: dangerous assertions mentioned in part 2 can now be caught by the new no-unsafe-type-assertion ESLint rule

Contact

You can start a direct discussion with me on LinkedIn (if you cannot send me a message directly, please add a note to your contact request).

French version

A French version is available on LinkedIn (initial version without the updates).

Next part

Before going into the topic's technical core, we will start this posts series with an introduction about why solving the 3 problems above is important for reliability and productivity.

DEV Community: Cyrille Tuzi

TypeScript strictly typed - Part 4: full static types

Remains of dynamic typing

Actual equality checks

No implicit conversions in conditions

Conditions shorthand notation

No strings and numbers mix

Conclusion

TypeScript strictly typed - Part 3: safe nullability

Required nullability checks

Required properties initialization

Objects vs records

Required indexes checks

Exact properties types

Handling inexact libraries

Evil !

Next part

TypeScript strictly typed - Part 2: full coverage typing

What is really TypeScript?

How typing works in TypeScript?

Required missing types

Ban any any

The unknown unknown type

Required errors checks

Who is this?

Should we add explicit types everywhere?

Required objects and arrays types

Required return types

Dangerous assertions

Do not use any library

A better TypeScript lib

Next part

TypeScript strictly typed - Part 1: configuring a project

When to enable strict options?

Frameworks status

Full configuration (the hard way)

TypeScript compiler options

ESLint

Oxlint

Biome

Deno

Notes

Automatic configuration (the easy way)

Next part

TypeScript strictly typed - Intro: reliability and productivity

TypeScript true promise

Reliability: bugs reduction

Productivity: easier and faster debug

Productivity: better autocompletion

Productivity: less tests to write

Scalability: safer refactoring

Design: better and simpler code

Put into perspective

Next part

TypeScript strictly typed: the true promise of TypeScript

The problem

Target audience

Changelog

Contact

French version

Next part

Ban any `any`

The unknown `unknown` type

Who is `this`?