feat/type-safe: Encourage type-safe coding practices with eslint-plugin-typesafe

[liangyuanruo]

Problem

TypeScript offers a powerful static typing system that can help us avoid painful bugs. However, there are also limitations that prevent the code from being fully type-safe.

For example, there is no way to enforce error handling even with this function signature:

function f(): never {
    throw new Error()
}

f() // compiles and runs

And, given a codebase of sufficient complexity, an unexpected error state will eventually occur that could bubble up to the entry point and crash the application. Because every valid JavaScript program must also be a valid TypeScript program, this problem is unlikely to ever be fixed by the compiler.

Solution

For a start, introduce a new linting rule named no-throw-sync-func from the new eslint-plugin-typesafe library, which prevents the use and further proliferation of throw statements within synchronous functions.

(full disclosure: I created the eslint-plugin-typesafe library during learning).

Like all linters, the plugin works by pattern matching against the Abstract Syntax Tree (AST) representation of the code and reporting violations to the linter. The rule is smart enough to prevent the use of throw where we probably shouldn't be using it most of the time (e.g. synchronous function declarations, expressions, and arrow function expressions methods), but also allow its use when it is probably safe to use it (e.g. async functions, Promise chaining, constructors).

As the team has already committed to using neverthrow for type safety, relatively few lines of code needed to be refactored to pass the new linting checks (with the exception of verification.service.ts). Code which ought to crash the application, such as bootstrapping code, were exempted from the linting rule.

As this is only a devDependency, eslint-plugin-typesafe does not ship to production.

Future work

This rule only prevents Errors from throwing, but not UnhandledPromiseRejections. Future work would include additional rules to try and address this shortcoming.

Exhaustive type checking in switch statements

Commits (such as 7d2509956898a41aa3400cd5c08f909ac5a714af) removes the need to use assertUnreachable in switch statements as one could simply rely on built-in exhaustive type checking against the argument type.

For example, the compilation will fail with "Not all code paths return a value" in the case below:

type MyNumber = 1 | 2

function test(x: MyNumber) {
    switch(x) {
        case 1:
            return 1
    }
}

Screenshots

Deploy Notes

New dev dependencies:

• eslint-plugin-typesafe - An ESLint plugin to encourage writing typesafe code

[mantariksh]

exciting, lgtm!