DEV Community: Giovanni Sarciotto

Implementing Async/Await

Giovanni Sarciotto — Mon, 15 Feb 2021 19:33:30 +0000

On my last post we saw the theory behind generators in JS/TS. In this article I will apply those concepts and show how we can use generators to build something similar to async/await. In fact, async/await is implemented using generators and promises.

Delving into async with callbacks

First we will show how we can deal with asynchronicity using generators by writing an example with callbacks.

The idea is as follows. When using callbacks, we pass some function that will be called whenever the async action has finished. So what if we don't call a callback, but instead call next on some generator? Better yet, what if this generator is the code that called our async function? That way we would have a code that calls some asynchronous process, stays paused while the asynchronous process isn't finished and return its execution whenever it is ready. Check this out:

If you don't know what is ...args in the implementation above, take a look at spread syntax.
We wrap our asynchronous operations with asyncWrapper. This wrapper just pass a callback to give control back to the generator main whenever the async process is completed. Notice how our code in main looks totally synchronous. In fact, just looking at main, we can't assert if there is anything asynchronous at all, although the yield gives a hint. Also notice how our code is very similar to what it would have been with async/await, even though we don't use Promises. This is because we are abstracting away the asynchronous portions from our consuming code main.

Using callbacks like above is fine, but there are some problems.

The code feels weird. Why should main know about asyncWrapper? main should be able to just call the async operation and everything should be handled in the background.
Where would we do error handling?
What if the asynchronous operations calls the callback multiple times?
What if we wanted to run multiple async operations in parallel? Since a yield corresponds to a pause in execution, we would need to add some complicated code to decide if when we call next is it to execute another operation or is it because an asynchronous operation has finished?
We have the problems that normal callbacks do (callback hell, etc).

Promises to the rescue

We can solve the problems above utilizing Promises. We will begin with a simple implementation with only one yield and no error handling and then expand it.

First we need to make our asynchronous operation addAsync return a promise, we will deal with the case that it doesn't later.

To solve 1, we need to change our wrapper to receive the code that we want to execute, becoming a runner. This way our runner does the things it needs and gives control back to our code whenever it is ready, while hiding how anything works from our code. The runner needs to do essentially two things:

Initialize our code.
Take the promise that is yielded to it, wait for its fulfillment and then give control back to our code with the resolved value.

And that's it! The problem 3 from our list is automatically solved whenever we use promises. The full code is the following:

Let's walk through the execution.

First we call our runner with the main function generator.
The runner initializes our generator and then calls it.next(). This gives control to main.
Main executes until the yield. It yields the return value of addAsync, which is a promise. This promise is unfulfilled at the moment.
Now the control is with the runner. It unwraps the value from the generator yield and gets the promise. It adds a .then that will pass the value of the fulfilled promise to main.
Whenever the promised is resolved and the runner gives control to main, the yield expression evaluates to the resolved value of the promise (5) and continues the execution until the end.

Dealing with non-Promises values

At the moment, our runner expects to receive a Promise. However, by the spec, you can await any value, Promise or not. Fortunately, to solve this is very easy.

Consider the following synchronous add function:

This code crashes our generator, since our generator tries to call a .then to the yielded value. We can solve this by using Promise.resolve. Promise.resolve(arg) copies arg if it is a Promise, otherwise it wraps arg in a Promise. So our runner becomes:

Now our code doesn't crash with non-Promise values:

If we run our code with addAsync, we will get the same behavior as before!

Dealing with errors

Since we are using Promises, we can easily get any error/rejection that happens in our asynchronous operations. Whenever a promise rejection occurs, our runner should simply unwrap the rejection reason and give it to the generator to allow for handling. We can do this with the .throw method:

Now not only we add a .then, but also a .catch to the yielded Promise and if a rejection occurs, we throw the reason to main. Notice that this also handles the case where we are performing a synchronous operation and there is a normal throw. Since our runner sits below main in the execution stack, this error will first bubble to the yield in main and be handled there in the try...catch. If there was no try...catch, then it would have bubbled up to the runner and since our runner doesn't have any try...catch it would bubble up again, the same as in async/await.

Dealing with multiple yields

We've come a long way. Right now our code is able to deal with one yield. Our code is already able to run multiple parallel asynchronous operations because we are using Promises, therefore Promise.all and other methods comes for free. Our runner, however isn't able to run multiple yield statements. Take the following generator:

Our runner will deal with the first yield just fine, however it won't correctly give control back to main at all in the second yield, the timeout will finish and nothing will happen. We need to add some iteration capability to the runner so that we can correctly process multiple yield statements. Look at the following code:

We use recursion with an IIFE to iterate through the generator. Instead of directly calling .next, we recursively call this IIFE with the unwrapped value of the promise. The first thing the function does is to give control back to the generator with the unwrapped value. The cycle then repeats if there is another yield. Notice that on the last yield (or if there isn't any), then the generator will end and give control back to the runner. The runner checks if the generator has ended and finishes execution if positive.

There is one problem however: if one of the promises rejects, then the cycle is broken and our runner doesn't run correctly. To fix this we need to add an error flag and call .next or .throw based on this flag:

Conclusion

We've implemented something really close to async/await. If you look at the V8 blog you will notice that our program does essentially the same thing. I suggest reading the blog post above, there is a cool optimization that if you await promises, then the engine is so optimized that your code will run faster than just using promises with a .then.

With this post I finish writing about generators, at least for now. There is an interesting topic that I didn't touch that is coroutines. If you want to read about it, I recommended this post.

For my next post I think I will write about Symbol or the Myers diff algorithm (the default diff algorithm for git). If you have any doubts, sugestions or anything just comment below! Until next time :)

Generators in Typescript

Giovanni Sarciotto — Mon, 15 Feb 2021 19:33:03 +0000

In this post we will understand what ES2015 generators are in Javascript/Typescript. Generators rely heavily on iterators, so if you don't know or would like to refresh your memory, take a look at my last post.

Introduction

As we know, iterators allows us to have total control of iterating through some structure, we get to decide if and when we get the next element of our iteration sequence, while hiding from our iterator's consumers implementation details of how we get these elements. However, everything has a cost, iterators can be quite tricky to implement since we have to keep track of the states that will control the flow of execution so that we can, for example, mark the iterator as complete.

Generators allows us to easily create iterators, making possible to implement some really cool stuff like stopping execution of functions to resume them later (sounds familiar to async/await?), pass values to the generator between these pauses and more.

The basics

Generators can be quite complicated and somewhat different from what we are used to, so pay close attention to the details. A generator declaration is very similar to a function declaration:

function* fooGen() {
    console.log("Hello from fooGen");
}
function foo() {
    console.log("Hello from foo")
}

You define a generator by using function* fooGen (you can actually do function * fooGen or function *fooGen). This is the only difference between our generator declaration and the declaration of our foo function but they actually behave very differently. Consider the following:

foo(); // Hello from foo
fooGen(); //

Our invocation of foo is as expected, however the invocation of fooGen didn't log anything. That seems odd, but this is the first big difference between functions and generators. Functions are eager, meaning whenever invoked, they will immediately begin execution while generators are lazy, meaning they will only execute our code whenever you explicitly tell them to execute. You may argue "but I ordered it to execute", however calling the generator doesn't execute its code, it only does some internal initialization.

So how do I tell a generator to execute our code? First let's see what fooGen() returns us. If we look at the type of fooGen, we will see the following: function fooGen(): Generator<never, void, unknown>, so let's look at what this Generator type is:

interface Generator<T = unknown, TReturn = any, TNext = unknown> extends Iterator<T, TReturn, TNext> {
    // NOTE: 'next' is defined using a tuple to ensure we report the correct assignability errors in all places.
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return(value: TReturn): IteratorResult<T, TReturn>;
    throw(e: any): IteratorResult<T, TReturn>;
    [Symbol.iterator](): Generator<T, TReturn, TNext>;
}

Wait, this interface has a next, return and throw methods isn't this an iterator? The answer is yes, but also notice that it is an iterable. So this interface is actually somewhat similar to the IterableIterator interface. If you want to know why they aren't the same, take a look at this question.

To order the generator to execute our code, we only need to call next:

foo(); // Hello from foo
const it = fooGen();
it.next() // Hello from fooGen

Let's return some value from our generator:

function* fooGen() {
    console.log("Hello from fGen");
    return "Bye from fGen";
}

const it = fooGen();
const result = it.next(); // Hello from fGen
console.log(result); // { value: 'Bye from fGen', done: true }
console.log(it.next()); // { value: undefined, done: true }

Notice that when you return something from a generator, it automatically completes the iterator, no need to manage state. Also notice that the value of the return expression is returned only once, subsequent calls to it.next return undefined in the value. Keep in mind that if there is no explicit return statement on your function or if the execution didn't reach a logical branch with the return, then undefined is assumed to be the return value.

The `yield` keyword

So far we didn't do anything exciting with generators, we just used them as some more complicated functions. As said in the introduction, we can pause the execution of generators. We achieve this using the yield keyword.

The yield keyword pauses the execution of our iterator.
Whenever we call next, the generator will synchronously execute our code until a yield or a return statement is reached (assuming no errors happened, which we will see later). If the generator was in a paused state and we call next again it will resume the execution from wherever it was paused from.

function*  fooGen() {
    console.log("Begin execution");
    yield;
    console.log("End execution");
}

const it = fooGen();
it.next();
console.log("The generator is paused");
it.next();

// Begin execution
// The generator is paused
// End execution

We can use yield to allow our generator to "return" multiple values (we say the generator yields these). We do this as follows:

function*  fooGen() {
    console.log("Begin execution");
    yield "This value was yielded";
    console.log("End execution");
}

const it = fooGen();
console.log(it.next());
console.log("The generator is paused");
it.next();
// Begin execution
// { value: 'This value was yielded', done: false }
// The generator is paused
// End execution

Notice that using yield doesn't complete the generator iterator. This is very powerful. One example of where this behavior is useful is for producing (infinite) sequences in a memory efficient way, for example, let's look how we can implement Fibonacci sequence using generators.

function* fibonacciGenerator() {
    const f0 = 0;
    yield f0;
    const f1 = 1;
    yield f1;
    let previousValue = f0, currentValue = f1, nextValue;
    while(true) {
        nextValue = previousValue + currentValue;
        previousValue = currentValue;
        currentValue = nextValue;
        yield nextValue;
    }
}

const it = fibonacciGenerator();
console.log(it.next().value); // 0
console.log(it.next().value); // 1
console.log(it.next().value); // 1
console.log(it.next().value); // 2
console.log(it.next().value); // 3

Notice how the lazy nature of generators is very useful and how the ability to pause execution allows us to generate infinite elements of the sequence (let's ignore possible integer overflows) whenever we want while only needing to save the previous and the current values. Quite nice isn't it? Notice that we don't actually need to complete a generator, we may only take some values and never call next again, although I wouldn't recommend that.

Passing values to the generator

There are two ways we can pass values to our generator. One is just as we would to a function, when creating the generator iterator. Let's expand the Fibonacci example to allow us to choose where to start the sequence:

function* fibonacciGenerator(startingPosition = 1) {
    const f0 = 0;
    if(startingPosition === 1) {
        yield f0;
    }
    const f1 = 1;
    if(startingPosition <= 2) {
        yield f1;
    }
    let previousValue = f0, currentValue = f1, nextValue;
    let currentPosition = 3;
    while(true) {
        nextValue = previousValue + currentValue;
        previousValue = currentValue;
        currentValue = nextValue;
        if(currentPosition >= startingPosition){
            yield nextValue;
        } else {
            currentPosition += 1;
        }
    }
}

const it = fibonacciGenerator();
console.log(it.next().value); // 0
console.log(it.next().value); // 1
console.log(it.next().value); // 1
console.log(it.next().value); // 2
console.log(it.next().value); // 3

console.log();

const it2 = fibonacciGenerator(4);
console.log(it2.next().value); // 2
console.log(it2.next().value); // 3
console.log(it2.next().value); // 5
console.log(it2.next().value); // 8
console.log(it2.next().value); // 13

The other way to pass values to a generator is through yield. You may be confused, since until now we have been using yield to, well, yield values from the generator. The truth is that yield is an expression, meaning it evaluates to some value. To clarify, let's look at this example:

function* fooGen() {
    while(true) {
        console.log(yield);
    }
}

const it = fooGen();
it.next();
it.next(1); // 1
it.next(2); // 2
it.next("heey"); // heey

The first call of it.next() will simply initiate execution of our generator iterator. Whenever it finds the yield expression, it will simply stop execution. Whenever we do it.next(1), the yield will evaluate to the value 1 and thus we have console.log(1) and so on.

The following is allowed:

function* accumulator(startingValue = 0): Generator<number, any, number> {
    let value = startingValue;
    while(true) {
        const input = yield value;
        value += input;
    }
}

const it = accumulator();
it.next();
console.log(it.next(3).value); // 3
console.log(it.next(10).value); // 13
console.log(it.next(-3).value); // 10

First the code is executed until the yield is found, yielding value (startingValue) . Whenever we call next(3), the expression yield value evaluates to 3, so now input === 3 and then value === 3. The cycle then repeats.

A comment above about types. I had to explicitly type the generator above so that Typescript could automatically detect the type of input. The type inference of yield expressions is an ongoing struggle.

Attention: Whatever you pass to the first invocation of next will be ignored, so watch out.

Error Handling

The code of our generator is just like any other function code, meaning we can put try...catch blocks inside it:

function* fooGen() {
    try {
        throw "Hi";
    } catch(err) {
        console.log("Err caught in fooGen:", err);
    }
    return "End of execution";
}

const it = fooGen();
it.next();
console.log(it.next())

// Err caught in fooGen: Hi
// { value: "End of execution", done: true }
// { value: undefined, done: true }

Notice that after the exception was handled, the generator continued its execution. If we didn't have a try...catch inside the generator, the exception would bubble as it would normally:

function* fooGen() {
    throw "Hi";
    return "End of execution";
}

const it = fooGen();
try {
    it.next();
} catch(err) {
    console.log("Exception caught outside of generator: ", err);
}
console.log(it.next());

// Exception caught outside of generator:  Hi
// { value: undefined, done: true }

Notice that our generator was completed because of the uncaught exception and didn't reach our return statement.

We can also throw errors from outside our generator to the inside:

function* fooGen() {
    console.log("Beginning of execution");
    try {
        yield;
    } catch(err) {
        console.log("Error caught inside fooGen: ", err);
    }
    return "End of execution";
}

const it = fooGen();
it.next();
console.log(it.throw("Hi from outside"));
console.log(it.next());

// Beginning of execution
// Error caught inside fooGen:  Hi from outside
// { value: 'End of execution', done: true }
// { value: undefined, done: true }

Notice that the error was thrown at the point that the generator execution paused. If there was no try...catch at that point, then it would have bubbled as normal.

An example of where we would like to use Generator.throw is with our Fibonacci example. As it is implemented, eventually we will run into an overflow. We can avoid this by using bigInt. In our case, we just want to complete the iterator when overflow happens.

function* fibonacciGenerator() {
    const f0 = 0;
    yield f0;
    const f1 = 1;
    yield f1;
    let previousValue = f0, currentValue = f1, nextValue;
    try {
        while(true) {
            nextValue = previousValue + currentValue;
            previousValue = currentValue;
            currentValue = nextValue;
            yield nextValue;
        }
    } catch(err) {
        return;
    }
}
let flag = true;
let value: number | void;
const it = fibonacciGenerator();
while(flag) {
    value = it.next().value;
    if(value === Number.MAX_SAFE_INTEGER || !Number.isFinite(value)) {
        it.throw("overflow");
        console.log("overflow detected");
        console.log(it.next());
        flag = false;
    } else {
        console.log(value);
    }
}

Whenever we detect an overflow from outside our generator, we simply call it.throw to complete it so that no other garbage value gets generated from it.

Generator Delegation

We may compose two or more generator using generator delegation yield* syntax:

function* g1() {
    yield 2;
    yield 3;
    yield 4;
  }

function* g2() {
    yield 1;
    yield* g1();
    yield 5;
  }

const iterator = g2();
console.log(iterator.next()); // {value: 1, done: false}
console.log(iterator.next()); // {value: 2, done: false}
console.log(iterator.next()); // {value: 3, done: false}
console.log(iterator.next()); // {value: 4, done: false}
console.log(iterator.next()); // {value: 5, done: false}
console.log(iterator.next()); // {value: undefined, done: true}

What happens is that whenever a yield* is encountered, every subsequent next or throw will go to the delegated generator, g2 in this case. This happens until g2 completes and the completion value of g2 is the value of yield* g2(). The subsequent call to next on g1 after g2 completes will continue from where g1 was paused as normal. This is how you may write coroutines in Javascript.

You can actually use yield* with any iterable, such as arrays.

Conclusion

Generators are a somewhat obscure but very interesting structure in Javascript. You probably won't find a generator in the wild, however it is good to know of their existence.

You can build very cool stuff with generators, Async/Await is implemented with generators and promises. If you want to learn more, see my next post.

Any doubts or sugestions, feel free to add a comment. Stay safe and until next time :)

Iterators in Typescript

Giovanni Sarciotto — Wed, 23 Dec 2020 13:29:39 +0000

In this post I will be explaining what iterators and iterables are in Javascript/Typescript as well two examples of how you can build these structures.

Introduction

Let's begin by demonstrating when you might need an iterator. Suppose you are implementing a data structure that can be iterated upon, let's say a tuple (fixed-length array). Your users will most likely want to transverse through the tuple by the usual order (first position, second position and so on...), so how would they do that? An example would be:

This approach is very bad! Our user needs to know implementation details to know how to iterate though the tuple. It also doesn't offer any protection, there are no safeguards against misuse of our tuple, e.g accessing a non-existing index of the value array. Furthermore, if we are not careful in the getValues method, we may allow our users to mutate the internals of our class since when returning an array we are effectively returning only a reference to said array.

We can avoid this error by cloning the array so that any changes we make to the array outside of the Tuple class will not be reflected to the internal representation in our class, but this approach is very bad for performance and memory usage.

We may solve the problems above by implementing a getValue method which returns a value of the tuple according to some private state.

This way is more safer than the previous implementation, but we will need to implement some method to allow resetting the iteration. This reset necessity is error prone, since we may forget to reset the index at the end of an iteration and get some unexpected behavior when doing another unrelated iteration. Another problem is: what we should do when calling getValue more times than there are elements in the tuple without resetting the index? In the implementation above I threw an error, but this might not be the best decision. We could return another value (like undefined) but this also is problematic, see Clean Code, and should be avoided whenever possible.

We can effectively solve these problems utilizing iterators.

Iterators

Conceptually, an iterator is an object that allows us to transverse some container (lists, arrays, ...). In Javascript this concepts translates to any Object that contains a next() method that returns an Object with the properties:

value: the next value in the iteration sequence. If present when done === true, then it is the iterator's return value.
done: a boolean which indicates if the sequence has finished or not.

After an iterator returns an Object with done === true and its return value, any additional calls to next() should simply return {done: true}.

In Typescript, we need to include at least es2015 in the lib options of our tsconfig.json to have type support for iterators and iterables. We have the following interface for an iterator:

Notice that you can pass arguments to next(), however this is not usual.

There are two other optional methods in the iterator interface, return and throw. Basically, return allows you to signal to the iterator that it should complete (setting done to true) and return its return value. Throw allows you to pass an error to the iterator which it may know how to handle. These two methods are more useful when you are dealing not with basic iterator but instead with a generator. I will explore generators in another post.

Iterables

An iterable is any object which implements the @@iterator method. This means that the object (or any object in it's prototype chain) must have a method, indexed by the Symbol.iterator key, that returns an iterator. Symbol.iterator is a a well-known Symbol, meaning that it is a built-in Symbol used internally by JS engine, for... of for example uses Symbol.iterator. You can think that an iterable is any object that you can iterate with a for... of loop.

Many JS built-in data structures are iterables, such as Arrays, Maps and Sets. Notice, however, that Object isn't an iterable by default. Note that an iterable may have multiple iterators. In this (unusual) situation we define the default iterator as the one returned by Symbol.iterator().

Besides the iterable interface, we have another interface called IterableIteror. This is useful for generators.

Example: Tuple

We will now see how we can implement an iterator for our Tuple example. While it is a simple example, it gives us an idea on how we may tackle harder scenarios.

Look how simple our Tuple is. We effectively separated the logic and state of transversing the structure from the tuple itself. The TupleIterator implementation is the following:

First we need to initialize the control states, index and done. Whenever the user calls next, we check to see if the iterator is completed and if yes we simply return {done: true}.

If we have reached the end of the tuple, return the length of the tuple as the return value while setting done to true. This is an example of how you can use the return value. We could have returned undefined as well without a problem, it is up to you to decide what to return. In a more complex structure, we could allow the user to cancel the iteration process (through the return method) and return how many items were iterated upon.

If the two if's above are false, then we just get the next value and update our index for the next iteration.

Notice how we solved the problems we pointed during the introduction, we aren't exposing any Tuple's internal representation to our user, they can't unsafely modify the representation (actually they can because of Typescript private keyword only enforces privacy at compile time, if we want to truly enforce privacy then we can use the proposal for private fields).

Our Tuple class is simple and only contains what matters, we would only need to implement a method to get an individual value of the tuple given an index to really have something usable. If we ever want to change the iteration logic, we can extend the class and override the @@iterator method to return another type of iterator while maintaining everything else the same.

To use our implementation, it is as simple as the following:

Example: BFS in a binary tree

In this example, we will see an implementation of the breadth-first search algorithm on a binary tree using iterators. This is just for illustration purposes, in the real world it would be better to implement this as a generator.

First we will define our binary tree:

Very simple implementation, each node contains a value and up to two children. Our tree is just a wrapper around the root node, we could implement insertion and other operations but I won't in order to not pollute the example.

Now for our iterator:

Our iterator receives a node from the tree and does some basic initialization. We will return the number of nodes iterated in the process as return value of our iterator, so we need to keep track of this in the numberOfNodes variable.

The currentRow variable is an array that will save the currentRow we are iterating. Usually when implementing BFS, we use a queue, but to avoid installing a dependency or implementing another structure to our example, our iterator simply saves a row and when needed gets another row via the getNewRow method (requires ES2019 for the Array.flat()). This is good enough for our purposes.

The bulk of our iterator is the next() method. First we check if the iterator is completed and if not check if we reached the end of our current row. If positive, then get another row and check is this new row isn't empty. If yes then our iteration is completed, set the flag and return the number of nodes that were iterated upon. If the iteration isn't completed, then get the next value and update our local index and node counter.

As an exercise, feel free to implement a depth-first search iterator in our tree.

Conclusion

Although iterators are old (they appeared in 2015) many people don't use/known them. Iterators are the building blocks for generators with which we can build some cool stuff, like cancelable asynchronous functions and coroutines. In fact, when the async/await syntax didn't exist, people emulated it with generators. I will cover generators in my next post, until then stay safe and happy Christmas!

Migrating and configuring Eslint with Angular 11

Giovanni Sarciotto — Mon, 30 Nov 2020 16:47:13 +0000

In this post we will walk through migrating and configuring an Angular 11 project to utilize ESLint and as a bonus add the Prettier formatter.

[21/01/2021 Update]: See the Prettier session.
[05/02/2021 Update]: Fixed Prettier parser error in HTML, see the Prettier configuration.
[27/02/2021 Update]: Updated ESLint config to work with eslint-config-prettier 8.x

Introduction

With Angular 11 release it was announced that the TSlint (deprecated in 2019) linter was to be replaced by ESLint and there was a 3rd-party solution to help with the migration as well as specific Angular linting rules for ESLint.

I will use a new project generated by the Angular CLI v11.0.2 as example, though it should be very straightforward to migrate an already existing project provided it doesn't use other tools that integrates with TSlint. The team at eslint-angular made a very good job of automating the process.

Migration

To do the migration we first need to install the convert-tslint-to-eslint schematic. Run the following in the root folder of your project(s):



ng add @angular-eslint/schematics

Now you have to choose the project you want to migrate. Then run the schematic as follows, replacing the {{}} bit for your project name:



ng g @angular-eslint/schematics:convert-tslint-to-eslint {{YOUR_PROJECT_NAME_GOES_HERE}}

What the schematics will do is look at the chosen project's tslint.json and try to match your TSlint rules with ESLint rules in a new file .eslintrc.json, adjust your Angular configurations to use ESLint instead of TSlint as well as replace tslint:disable comments to their ESLint equivalent.
Pay attention to your terminal output, any rules that it can't match or if it needed to install any additional dependencies will be shown there.

And that's it, the migration should be over. If you are feeling brave you can delete the tslint.json file and uninstall both tslint and codelyzer from your project or test to see if it works and delete them later!

Customizing ESLint

If you already had customized your TSlint rules, then the schematics should have taken care of converting them to ESLint equivalents. However if it couldn't do it or if you don't like the current rules, you can easily modify your configurations. First let's take a look at how ESLint configurations are structured.

ESLint configuration structure

ESLint allows for heavy customization. It allows for plugins, different parsers, overrides, extending from others configurations defined elsewhere and more. I will cover the basics to allow us to understand what we are doing and if you want to learn more feel free to look at the docs.

Let's take a look at the configuration that was generated from a new CLI project:



.eslintrc.json
{
  "root": true,
  "ignorePatterns": [
    "projects/**/*"
  ],
  "overrides": [
    {
      "files": [
        "*.ts"
      ],
      "parserOptions": {
        "project": [
          "tsconfig.json",
          "e2e/tsconfig.json"
        ],
        "createDefaultProgram": true
      },
      "extends": [
        "plugin:@angular-eslint/ng-cli-compat",
        "plugin:@angular-eslint/ng-cli-compat--formatting-add-on",
        "plugin:@angular-eslint/template/process-inline-templates"
      ],
      "rules": {
        "@angular-eslint/component-selector": [
          "error",
          {
            "type": "element",
            "prefix": "app",
            "style": "kebab-case"
          }
        ],
        "@angular-eslint/directive-selector": [
          "error",
          {
            "type": "attribute",
            "prefix": "app",
            "style": "camelCase"
          }
        ]
      }
    },
    {
      "files": [
        "*.html"
      ],
      "extends": [
        "plugin:@angular-eslint/template/recommended"
      ],
      "rules": {}
    }
  ]
}

Notice that most of the configuration is inside the overrides field. This is because in an Angular project we have Typescript and HTML files. So each file type that we want to lint will need different parsers and plugins. To avoid conflicts, ESLint provides us with the overrides field to allows us to separate the rules for different file types (notice the *.html and *.ts in the files array of each entry of the overrides array).

Another important field to look at is the extends field. It allows us to utilize configurations defined elsewhere inside this file. These other configuration files can be created by us or installed via npm or from the internet in general. A very popular configuration is the AirBnB's one.

In my configuration above, we see configurations that come with the @angular-eslint plugin: "plugin:@angular-eslint/ng-cli-compat" and "plugin:@angular-eslint/ng-cli-compat--formatting-add-on". These two configurations were created to make it easy for the @angular-eslint team to do the automatic matching of TSlint rules and ESLint ones. I find them weak, for example: it won't warn or show as error unused variables. If we only want to change a few rules, then we can just use the rules field. I want a more drastic change so I will utilize other configurations such as @angular-eslint/recommended, which @angular-eslint team recommends.

Changing the configurations

First I will remove both "plugin:@angular-eslint/ng-cli-compat" and "plugin:@angular-eslint/ng-cli-compat--formatting-add-on" from the "extends" field and add the "plugin:@angular-eslint/recommended". Make sure you are making the modifications in the Typescript entry of overrides.

For now, our configuration looks like this:



"extends": [
        "plugin:@angular-eslint/recommended",
        "plugin:@angular-eslint/template/process-inline-templates"
      ],

The standard Typescript rules, parser and configurations for ESLint with Typescript comes from typescript-eslint. The migration schematics already installed it for us, since @angular-eslint uses it under the hood. I will then extends the following configurations: eslint:recommended, plugin:@typescript-eslint/recommended and plugin:@typescript-eslint/recommended-requiring-type-checking. You can see what these configs rules are in these links: eslint:recommended, typescript-eslint/recommended and typescript-eslint/recommended-requiring-type-checking, but a brief explanation is that eslint:recommended adds some basic rules such as no unused variables, typescript-eslint/recommended disables some conflicting rules from eslint:recommended for usage with Typescript and adds some general Typescript rules, at last typescript-eslint/recommended-requiring-type-checking adds some types rules. The configuration looks like this:



"extends": [
        "plugin:@angular-eslint/recommended",
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@typescript-eslint/recommended-requiring-type-checking",
        "plugin:@angular-eslint/template/process-inline-templates"
      ],

The order matters. If we had included typescript-recommended before eslint:recommended, then the conflicting rules would be enabled.

Test the configuration

Check to see if everything is working. For example, in your configuration above, the no unused variables is enabled, so open a Typescript file and create a new variable and check if the linting works.

In the image above, I'm using VSCode editor, you can install an extension on it so that it runs the linter inside the editor and show errors while you type.

If you would like to change specific rules, you can do so at the "rule" entry.

Bonus: Adding Prettier

[21/01/2021 Update]: There are problems with the inline-templates plugin and prettier, see this issue. If you use inline-templates, then I would recommend changing to external templates or don't do the prettier integration for now.

First of all, what is Prettier? It is an opinionated code formatter. And the best of all is that you can enable it to run when ESLint lints your code or in your CI pipeline! No more declined PRs because of bad formatting, just agree on a set of rules with your team and let it do the formatting for you.

Installing dependencies

We will need to add 3 dependencies (as dev dependencies) to our project: prettier, eslint-config-prettier and eslint-plugin-prettier.



npm install -D prettier eslint-config-prettier eslint-plugin-prettier

They are needed for doing the formatting but also disabling some formatting rules of ESLint so that there are no conflicts between Prettier and ESLint.

Integrating Prettier and ESLint

[27/02/2021 Update]: In eslint-config-prettier version 8, there is no need to extend prettier/@typescript-eslint anymore. If you are in a version below 8, just add the entry before plugin:prettier/recommended.

Now on the .eslintrc.json file, we just need to add the plugins to our "extends" field:



"extends": [
        "plugin:@angular-eslint/recommended",
        "plugin:@angular-eslint/template/process-inline-templates",
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@typescript-eslint/recommended-requiring-type-checking",
        "plugin:prettier/recommended"
      ],

If you want to enable the formatting in your .html files, then you need to add these two new lines in the HTML entry of the "overrides" field.



"extends": [
        "plugin:@angular-eslint/template/recommended",
        "plugin:prettier/recommended"
      ],

IMPORTANT: The prettier entries should be at the end of the "extends" array and in the order above. This is so that the prettier config disables ESLint rules that conflicts with its own rules.

Optional: Customizing Prettier

Although Prettier is opinionated and comes with defaults, you can do some customizations. For that we need to create a .prettierrc file (you can also create the file as .js or .json) in the root folder and put the configurations that we want. You can see the options here.

My current options are:



{
    "tabWidth": 4,
    "useTabs": true,
    "semi": true,
    "singleQuote": false,
    "quoteProps": "as-needed",
    "trailingComma": "none",
    "bracketSpacing": true,
    "arrowParens": "always",
    "overrides": [
        {
            "files": "*.component.html",
            "options": {
                "parser": "angular"
            }
        },
        {
            "files": "*.html",
            "options": {
                "parser": "html"
            }
        }
    ]
}

[05/02/2021 Update]: For some reason, Prettier wasn't able to decide a parser for *.component.html files. To solve this the overrides section above was added to the .prettierrc to force it to use a parser. Thanks @singhshubham97 for pointing this out.

Final configuration



{

  "root": true,

  "ignorePatterns": [

    "projects/*/"

  ],

  "overrides": [

    {

      "files": [

        ".ts"

      ],

      "parserOptions": {

        "project": [

          "tsconfig.json",

          "e2e/tsconfig.json"

        ],

        "createDefaultProgram": true

      },

      "extends": [

        "plugin:@angular-eslint/recommended",

        "plugin:@angular-eslint/template/process-inline-templates",

        "eslint:recommended",

        "plugin:@typescript-eslint/recommended",

        "plugin:@typescript-eslint/recommended-requiring-type-checking",

        "plugin:prettier/recommended"

      ],

      "rules": {

        "@angular-eslint/component-selector": [

          "error",

          {

            "type": "element",

            "prefix": "app",

            "style": "kebab-case"

          }

        ],

        "@angular-eslint/directive-selector": [

          "error",

          {

            "type": "attribute",

            "prefix": "app",

            "style": "camelCase"

          }

        ]

      }

    },

    {

      "files": [

        ".html"

      ],

      "extends": [

        "plugin:@angular-eslint/template/recommended",

        "plugin:prettier/recommended"

      ],

      "rules": {}

    }

  ]

}

Conclusion

In this article we saw how to migrate a TSlint Angular project to an ESLint one. We did just some basic customization, we could have added linting for .css or .scss files or specific linting for your .spec.ts files. I recommend you taking a look at the ESLint ecosystem and configuring it to your liking!

DEV Community: Giovanni Sarciotto

Implementing Async/Await

Delving into async with callbacks

Promises to the rescue

Dealing with non-Promises values

Dealing with errors

Dealing with multiple yields

Conclusion

Generators in Typescript

Introduction

The basics

The yield keyword

Passing values to the generator

Error Handling

Generator Delegation

Conclusion

Iterators in Typescript

Introduction

Iterators

Iterables

Example: Tuple

Example: BFS in a binary tree

Conclusion

Migrating and configuring Eslint with Angular 11

Introduction

Migration

Customizing ESLint

ESLint configuration structure

Changing the configurations

Test the configuration

Bonus: Adding Prettier

Installing dependencies

Integrating Prettier and ESLint

Optional: Customizing Prettier

Final configuration

Conclusion

The `yield` keyword