Why did I migrate my [blog](https://github.com/cesalberca/blog) for the third and last (hopefully) to Web Components? In this article I'll explain why.



## Why?

Initially my blog was powered by [Jekyll](https://jekyllrb.com/), then I migrated it to [Vue](https://vuejs.org/) and last week I was thinking about migrating it to [Nuxt](https://nuxtjs.org/) so that I could improve my SEO and performance. In the last moment I decided to approach it with a more _agnostic_ solution that could also improve my SEO. So I finally decided to migrate it to [LitElement](https://lit-element.polymer-project.org/).

Why this change all of a sudden? Well, I was starting to wonder things that I had taken for granted: Is it so hard to have good SEO without using techniques like SSR or some frameworks like static site generators like [Gatsby](https://www.gatsbyjs.org/)? Is it really necessary to add dependencies with **thousands upon thousands of lines of code**, with **so many moving parts** and **so many abstractions** to build a website nowadays? It _can't be that hard_. Or at least it shouldn't be. That's when [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) come into play, which a part from removing the need of using a complex framework they have [good SEO](https://developers.google.com/search/docs/guides/javascript-seo-basics#web-components).

> It can't be _that complicated_.

When I started my blog in Vue there wasn't a possibility to use Web Components which would work on all modern browsers, but today, it is a possibility. If choosing Web Components means also that I **bet on the platform**, **have less moving parts**, **fewer dependencies**, **less magical transpilation**, then I would have less surface for errors and that would make my code **more robust**, so it would **last longer**.

Here you have the code for my blog: [https://github.com/cesalberca/blog](https://github.com/cesalberca/blog). Without further ado, let's answer the very first question: **how do we serve Web Components?**

## Bundling web components

To serve Web Components we should start looking to include [Webpack](https://webpack.js.org/) o [Parcel](https://parceljs.org/), right? But now that we are rethinking everything, do we really need a bundler? Yes, it seems like a crazy idea, right? Do we really need to create a single file —a bundle— to serve to the client? Why is it necessary today when ESModules are [supported by all modern browsers](https://caniuse.com/#feat=es6-module).

> Do we really need a bundler?

All of these questions led me to choose [Snowpack](https://www.snowpack.dev/), which proposes taking the dependencies and moving them to a `web_modules` and in our code instead of doing:

```typescript
import { customElement } from 'lit-element'
```

We do this:

```typescript
import { customElement } from '/web_modules/lit-element.js'
```

Because the first way of importing is not native —not now [at least](https://github.com/WICG/import-maps)— and browsers don't understand, that's why the piece of the bundler was so **import**ant. Every time the bundler saw some import it would associate it with `node_modules` and so it included the related code in the bundle.

### Snowpack

To use Snowpack you have to take into account the following:

1. The imports must include the extension. At least if we don't want to use Babel (although we can avoid putting the extension with [this configuration](https://www.snowpack.dev/#importing-packages-by-name))
   . With TypeScript, you have to include the extension `.js`. There is an [issue](https://github.com/microsoft/TypeScript/issues/16577) where this is mentioned.
2. When you install dependencies you have to include them in the `package.json` inside the [Snowpack configuration](https://www.snowpack.dev/#whitelisting-dependencies). In my case it was necessary because I wanted to use RxJS, which has the same problems with certain exports.

```json
{
  "snowpack": {
    "webDependencies": [
      "lit-html",
      "lit-element",
      "lit-html/directives/class-map.js",
      "lit-html/directives/style-map.js"
    ],
    "dedupe": ["lit-element", "lit-html"]
  }
}
```

If you find that this command works:

```bash
snowpack --include "src/**/*.ts"
```

Then don't whitelist the dependencies inside the `webDependencies` option.

Although be careful, because the moment you add a web dependency the `--include "src/**/*.ts"` does not do anything, so you should remove it.

3. You need to launch a local server. Opening the `index.html` file won't work because of the script type module. In this case I chose [servor](https://github.com/lukejacksonn/servor) because of its simplicity and its option of auto-reload.

4. Regenerate the `web_modules` when you add a new dependency. You can add a script `prepare` to do so:

```json
{
  "prepare": "snowpack"
}
```

5. If you use [inversify](http://inversify.io/) with [inversify-props](https://github.com/CKGrafico/inversify-props) then you should add the following configuration in the `package.json`:

```json
{
  "snowpack": {
    "namedExports": {
      "inversify-props": ["injectable", "inject"]
    }
  }
}
```

That is probably all you need to know for now of Snowpack, a tool that **saves us the bundle generation time**, which can shave off precious seconds in developments and **avoids complexity**.

## Migration process

In my projects I bet on an architecture which **separates the logic of what my application does from how the user interacts with system**. I often follow an architecture with 4 layers: **application**, **domain**, **infrastructure** and **ui**. This has allowed me to migrate from Vue to LitElement changing mainly the **ui** layer. If you want to know more about this you can watch a talk a gave about [this](https://www.youtube.com/watch?v=NpjecaAgcVQ) (in Spanish).

What other layers did I need to change? The **infrastructure** layer, because when you don't have bundler the imports of Markdown are handled by Webpack with [frontmatter-markdown-loader](https://www.npmjs.com/package/frontmatter-markdown-loader). I had to replace the retrieval of articles with HTTP requests using [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API).

Something so simple as importing non JavaScript files was something that was primarily introduced by Webpack and other bundlers, but is something not native, not [at moment](https://github.com/tc39/proposal-module-attributes) at least. Moreover, CSS, image and SVG imports inside JavaScript can be replaced by the use of link, img tags and inlining SVG respectively.

Something that I like about Vue is the reactivity and how you can even create reactive objects outside of the components using the [Vue.observable](https://vuejs.org/v2/api/#Vue-observable) API. I was using this API mainly to handle the little state I have, which is to change the language and theme. With LitElement there is nothing like this, and as I didn't want to couple the state with the view I had to rely on a solution like [RxJS](https://rxjs-dev.firebaseapp.com/) where I stored the state in a BehaviourSubject.

Something that I missed was to avoid prop drilling using the [Provide/Inject](https://vuejs.org/v2/api/#provide-inject) API. With LitElement there is nothing like this or React's [context API](https://reactjs.org/docs/context.html) (which is where the Provide/Inject API comes from). Now that I have my state centralized and being able to do dependency injection with [inversify-props](https://github.com/CKGrafico/inversify-props) I could emulate this functionality.

## Configuration

We don't need a bundler, but we still need to execute certain tasks. For example, when we compile TypeScript, it doesn't copy the HTML, CSS and assets files in the compiled sources. Moreover, something like minifying images which was so simple with a Webpack plugin now we have to do it invoking the image processing library.

At the end everything has its pros and cons. This I would say has been the biggest con, and that is that **many tools are not really adapted to ESModules**.

### Development

The copying of files I do it with [cpx](https://www.npmjs.com/package/cpx) which has a watch mode. I included this in the `package.json`:

```json
{
  "scripts": {
    "prestart": "run-s -l clean",
    "start": "run-p -l server copy:watch compile:watch",
    "clean": "rimraf dist",
    "copy:watch": "run-p copy:assets:watch copy:dependencies:watch",
    "copy:assets:watch": "cpx \"src/**/*.{jpg,jpeg,svg,png,css,html,ico,md}\" dist/ -w",
    "copy:dependencies:watch": "cpx \"web_modules/**/*.js\" dist/web_modules -w",
    "compile:watch": "tsc -w",
    "server": "servor dist index.html --reload --browse",
    "dependencies": "snowpack",
    "prepare": "run-s dependencies"
  }
}
```

You'll see that I make use of the weird commands: `run-s` and `run-p`. Well, I use that in order to execute several processes at the same time, like the compiler watch, the copying watch and the local server. You can't wait for one process to finish to start another one because it will never finish executing, not until we stop it manually.

`run-s` and `run-p` come from the package [npm-run-all](https://www.npmjs.com/package/npm-run-all). The `s` means "sequentially" and the `p` means "parallel".

With an `index.html` file where we import a script with type module we will be able to see something:

```html
<!DOCTYPE html>
<html lang="es">
  <head>
    <link rel="stylesheet" rel="preload" href="ui/styles/base.css" />
    <script type="module" src="./index.js"></script>
  </head>
  <body>
    <cesalberca-blog></cesalberca-blog>
  </body>
</html>
```

### Production

To make the production build we will need to have a script similar to the `start` script except we won't need the watch mode. I also minify the images here. I don't do any other type of [minification](<https://en.wikipedia.org/wiki/Minification_(programming)>), [uglifying](https://www.quora.com/What-does-uglify-mean) or [tree shaking](https://en.wikipedia.org/wiki/Tree_shaking). I'm aware of the costs of not doing this and for the moment I think they are trivial to the user.

Something that we get for free without a bundle is that the browser will cache the files for you.

The `package.json` now looks like this:

```json
{
  "scripts": {
    "prebuild": "run-s -l clean",
    "build": "run-s -l dependencies copy compile",
    "postbuild": "run-s optimize",
    "clean": "rimraf dist",
    "copy": "run-s copy:assets copy:dependencies",
    "copy:assets": "cpx \"src/**/*.{jpg,jpeg,svg,png,css,html,ico,md}\" dist/",
    "copy:dependencies": "cpx \"web_modules/**/*.js\" dist/web_modules",
    "compile": "tsc",
    "optimize": "ts-node scripts/optimize.ts",
    "dependencies": "snowpack",
    "prepare": "run-s dependencies"
  }
}
```

### TypeScript

In order for TypeScript's type resolution to work I had to add the following configuration to `tsconfig.json`:

```json
{
  "compilerOptions": {
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "/web_modules/*.js": ["node_modules/@types/*", "node_modules/*", "web_modules/*.js"]
    }
  }
}
```

So now when we do an import from `/web_modules` TypeScript knows to resolve the imports from `node_modules`.

Moreover, I had to add `inlineSourceMap` and `inlineSources` to true in order to be able to debug with breakpoints.

My whole `tsconfig.json` configuration is this:

```json
{
  "compilerOptions": {
    "target": "es2018",
    "module": "esnext",
    "outDir": "dist",
    "moduleResolution": "node",
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "inlineSourceMap": true,
    "inlineSources": true,
    "resolveJsonModule": true,
    "types": ["jest", "reflect-metadata", "node"],
    "lib": ["esnext", "dom", "dom.iterable"],
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "/web_modules/*.js": ["node_modules/@types/*", "node_modules/*", "web_modules/*.js"]
    },
    "allowSyntheticDefaultImports": true
  },
  "include": ["src/*"],
  "exclude": ["node_modules"]
}
```

### Testing

For testing, I use [Jest](https://jestjs.io/). Here I had to adapt the configuration, so it worked correctly. In this case I had to add the following dependencies:

```bash
npm i @babel/core @babel/plugin-proposal-decorators @babel/preset-env @babel/preset-typescript @types/jest babel-jest jest jest-ts-webcompat-resolver -DE
```

As you can see we added Babel, but... Why? Well, Jest **executes directly TypeScript**. However, Jest, does not know how to read a TypeScript file. That's why we need to erase all type information so Jest can parse and execute that file. This is explained more in detail [here](https://iamturns.com/typescript-babel/).

In this case we only need to use Babel for the tests, that's why I included this configuration in the `babel.config.js`:

```javascript
module.exports = {
  env: {
    test: {
      presets: [['@babel/preset-env', { targets: { node: 'current' } }], '@babel/preset-typescript'],
      plugins: [
        [
          '@babel/plugin-proposal-decorators',
          {
            legacy: true,
          },
        ],
      ],
    },
  },
}
```

Lastly my `jest.config.js`:

```javascript
module.exports = {
  coverageDirectory: 'coverage',
  coverageReporters: ['text-summary', 'lcov'],
  resolver: 'jest-ts-webcompat-resolver',
  moduleNameMapper: {
    '/web_modules/(.*)': '<rootDir>/web_modules/$1',
  },
  setupFiles: ['<rootDir>/tests/set-up.ts'],
}
```

The [jest-ts-webcompat-resolver](https://www.npmjs.com/package/jest-ts-webcompat-resolver) is a package that helps resolve imports from TypeScript with the extension.

With that we can now run our tests.

## Conclusions

The code of my blog you can read it [here on Github](https://github.com/cesalberca/blog). I'm very satisfied with the result. I employed a lot of time investigating how to approach common problems in the most native way. At the end I managed to achieve my objectives: **have a better SEO**, **simplify** and **bet on the platform**.

I think for now tooling must try and adapt to the modern way of doing things and leave behind non-native APIs. It's something that [Deno](https://deno.land/) is doing. It's something that LitElement is doing. **And it's something that we should be doing**.

Why I migrated my blog to Web Components?

In this tutorial we will see how to migrate a codebase from JavaScript to [TypeScript](https://www.typescriptlang.org/). We will migrate the code of my talk Advanced JavaScript Pattern (oh the irony, right?). [Here you have the repository](https://github.com/cesalberca/advanced-javascript-patterns). You can also watch [my talk here in Spanish](https://www.youtube.com/watch?v=3nPPRvRcoo0&feature=youtu.be). Let's start!



## Configuration

First of all is to include a `tsconfig.json` file in the root of your project. This file we will set the options for TypeScript:

```json
{
  "compilerOptions": {
    "moduleResolution": "node",
    "outDir": "./dist",
    "allowJs": true,
    "target": "esnext"
  },
  "include": ["./src/**/*"],
  "exclude": ["node_modules"]
}
```

`moduleResolution` specifies how [TypeScript is going to resolve the dependencies](https://www.typescriptlang.org/docs/handbook/module-resolution.html).

`outDir` will be the directory in which the TypeScript code will be compiled to. This will be the code that we will deploy or execute.

The `allowJs` option allows us to do an incremental migration, **which is great**!

`target` allows us to set the JavaScript version in which we want to compile to. We could also even set it to version `es3` making our code be executable in older browsers.

Lastly, with `include`, we define which routes TypeScript's compiler should be checking. By convention, we should have our code in the `src` directory.

## Installation

Now we install TypeScript as a `dev-dependency`: `npm i typescript -DE`. We add to the scripts of the `package.json` the script of compilation:

```json
{
  "scripts": {
    "compile": "tsc --pretty"
  }
}
```

Because we don't have any `.ts` file that we can compile we'll see that the compilation is successful:

![image-20191112213355655](/assets/images/articles/migrating-to-typescript/image-20191112213355655.png)

## Migration

Let's try change the extension from `.js` to `.ts` and compile again:

![image-20191112213602568](/assets/images/articles/migrating-to-typescript/image-20191112213602568.png)

What?! It compiles correctly! Well yes, **any JavaScript file is valid TypeScript code**.

TypeScript by default infers anything that it doesn't understand as [any](https://www.typescriptlang.org/docs/handbook/basic-types.html#any). `any` is not cool, _not at all_. With the option `noImplicitAny` set to `true` in our `tsconfig.json` we will get an error in places TypeScript infers something to `any`.

```json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}
```

Now when we compile we'll start to see some errors. To fully get TypeScript's advantages like: safety, refactorings and improved DX we need to help it by stating the types we use, and that's what we are going to do:

```javascript
export function multiply(a = 1, b = 1) {
  return a * b
}

export function priceAfterTaxes(price, tax = multiply(21, 0.01)) {
  return price + price * tax
}
```

Will become:

```typescript
export function multiply(a = 1, b = 1) {
  return a * b
}

export function priceAfterTaxes(price: number, tax = multiply(21, 0.01)) {
  return price + price * tax
}
```

Here we see that TypeScript doesn't need us to specify that `a` or `b` in the function `multiply` are `numbers` given that it's smart enough to infer it. Moreover, if it receives two parameters that are numbers, and we multiply them, what would the return type be? Well, obviously `number`.

### Never

Let's check the `propValidator` file:

```javascript
export function isRequired() {
  throw new TypeError('Argument is required')
}

export function capitalize(string = isRequired()) {
  return string.toUpperCase().slice(0, 1) + string.slice(1)
}
```

It becomes:

```typescript
export function isRequired(): never {
  throw new TypeError('Argument is required')
}

export function capitalize(string: string = isRequired()) {
  return string.toUpperCase().slice(0, 1) + string.slice(1)
}
```

`never` is a very interesting type which specifies something that's never going to change. It's not very common to use it, but in this case this function never returns anything. Here we see that TypeScript adapts to the great flexibility that JavaScript offers. It's in very few cases where we can't model a JavaScript program in TypeScript and there is always the `any` escape hatch.

If you want, you can checkout the basic types in [the official documentation](http://www.typescriptlang.org/docs/handbook/basic-types.html)

### Classes

With classes, we see certain advantages in respect to their counterparts in JavaScript:

```javascript
export class Subject {
  constructor() {
    this.observers = []
    this._counter = 0
  }

  set counter(value) {
    // https://github.com/tc39/proposal-private-fields
    this._counter = value
    this.notifyObservers()
  }

  get counter() {
    return this._counter
  }

  incrementCounter() {
    this.counter++
    this.notifyObservers()
  }

  addObserver(observer) {
    this.observers.push(observer)
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.notify(this))
  }
}
```

In TypeScript is:

```typescript
import { Observer } from './Observer'

export class Subject {
  private _counter = 0
  private readonly observers: Observer[]

  constructor() {
    this.observers = []
  }

  set counter(value) {
    // https://github.com/tc39/proposal-private-fields
    this._counter = value
    this.notifyObservers()
  }

  get counter() {
    return this._counter
  }

  incrementCounter() {
    this.counter++
    this.notifyObservers()
  }

  addObserver(observer: Observer) {
    this.observers.push(observer)
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.notify(this))
  }
}
```

Here we don't need to use anymore the convention `_` to specify that a property or method is private. With TypeScript, we have available to us [privacy](http://www.typescriptlang.org/docs/handbook/classes.html#public-private-and-protected-modifiers) with the `private` keyword –we also have `protected` and `public`–. By default, if we don't specify anything, it's `public`.

We also don't need to declare the types and do the assignations in the constructor like we do in the `Observer` file:

```javascript
export class Observer {
  constructor(subject) {
    this.subject = subject
    this.subject.addObserver(this)
    this.value = 0
  }

  display() {
    return `Observer counter: ${this.value}`
  }

  notify(subject) {
    this.value = subject.counter
  }
}
```

We can do as follows:

```typescript
import { Subject } from './Subject'

export class Observer {
  private value = 0

  constructor(private readonly subject: Subject) {
    this.subject.addObserver(this)
  }

  display() {
    return `Observer counter: ${this.value}`
  }

  notify(subject: Subject) {
    this.value = subject.counter
  }
}
```

Moreover, if in the constructor we specify `private` or `public`:

```typescript
class Foo {
  foo: number

  constructor(foo: number) {
    this.foo = foo
  }
}
```

It's the same as this:

```typescript
class Foo {
  constructor(public foo: number) {}
}
```

### Generics

Let's see a more complex example:

```typescript
// Well later see how we can improve the any return type
export function createSafe(target: object): any {
  const handler = {
    get(target: object, name: string | number | symbol, receiver: any) {
      if (hasKey(target, name)) {
        const targetElement = Reflect.get(target, name, receiver)

        if (isObject(targetElement)) {
          return createSafe(targetElement)
        }

        return targetElement
      }

      return notDefined
    },
  }
  return new Proxy(target, handler)
}

export const notDefined: object = new Proxy(
  {},
  {
    get() {
      return notDefined
    },
  },
)

export const either = (value: object, fallback: any) => (value === notDefined ? fallback : value)

const isObject = (obj: object) => typeof obj === 'object'
const hasKey = (obj: object, key: string | number | symbol) => key in obj
```

Let's improve the types, because we are making use of `any` and we shouldn't. Given the nature of the [proxies](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) that we are creating, the return type is the same as the type of element we are passing through the parameter of the function. Right now as we are marking it as `any` we could make mistakes and TypeScript wouldn't be able to tell us:

```typescript
const object = createSafe({ foo: 'bar' })
object.propertyThatDoesNotExist // OK
```

So we'll have a runtime error because we couldn't catch it in compilation. We can't even get the IDE to tell use what properties this object has. So let's be more exact with the types:

```typescript
export function createSafe<Target>(target: Target): Target {
  const handler = {
    get(target: Target, name: string | number | symbol, receiver: any) {
      if (hasKey(target, name)) {
        const targetElement = Reflect.get(target, name, receiver)

        if (isObject(targetElement)) {
          return createSafe(targetElement)
        }

        return targetElement
      }

      return notDefined
    },
  }
  return new Proxy(target, handler)
}
```

Here we are making use of a [generic](https://www.typescriptlang.org/docs/handbook/generics.html). Generics allow us to define a type which can take different values overtime, which is what we need for this function. Given that we have only one parameter TypeScript knows that the parameter `target` will obtain the value of the `Target` type:

```typescript
const foo = createSafe('hello') // foo is inferred as a string
const bar = createSafe(1) // bar is inferred as a number
```

Yet if we compile we'll see that we get the following error:

![image-20191113201553918](/assets/images/articles/migrating-to-typescript/image-20191113201553918.png)

What happened? Well, given that any type can be set to `Target` that raises a problem, as we only want `Target` to take any type that is of an object kind. So what we want here is [to constrain the type](https://www.typescriptlang.org/docs/handbook/generics.html#generic-constraints) that we can assign to `Target` to the `object` type:

```typescript
export function createSafe<Target extends object>(target: Target): Target {
	...
}
```

With `Target extends object` we are stating that `Target` can only be of type `object`.

Uff, César, this seems very complex, right? Well, yes, I wanted to show a complex example just in case you have a similar problem. The rest of the code was pretty straightforward, right?

## We become stricter

What if I told you that you can make you program fireproof? Well, you can, here the [strict more](https://www.typescriptlang.org/docs/handbook/compiler-options.html) comes into play:

```json
{
  "compilerOptions": {
    "strict": true
  }
}
```

With this option TypeScript will offer more checks like nulls, this, bind, call, apply and property initialization. I also like setting the following options:

```json
{
  "compilerOptions": {
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedParameters": true,
    "noUnusedLocals": true,
    "forceConsistentCasingInFileNames": true
  }
}
```

Now TypeScript will tell me when did I miss adding a branch in a switch statement, when did I put a parameter in a function that I don't use, when I don't use a symbol, when all the branches of a function return a value or when I'm not being consistent of the capitalization of imports in different files.

## Tests

This project has tests done with [Jest](https://jestjs.io/). In any refactor is a good idea to have a safety net like a test suite. If we make mistakes the tests will tell us. We also have TypeScript to check errors, but if TypeScript has errors, we won't be able to compile and deploy to production, right? Well, no, TypeScript always compiles to JavaScript, we could just _simply_ ignore the errors. Although, are you sure you want to deploy a program with possible errors?

Let's run the tests:

```bash
npm test
```

![image-20191113202705616](/assets/images/articles/migrating-to-typescript/image-20191113202705616.png)

Oups, what is happening? Well, [Jest](https://jestjs.io/), the test runner that we are using, doesn't know how to compile TypeScript, which requires some configuration. We add [Babel](https://babeljs.io/) so it can erase the types and then run the tests:

```bash
npm i @babel/preset-typescript -DE
```

We need to create a `babel.config.js` file in the root of our project:

```typescript
module.exports = {
  presets: ['@babel/preset-typescript'],
}
```

We add some configuration to `jest.config.js`:

```typescript
module.exports = {
  ...
  rootDir: 'src',
  moduleFileExtensions: ['ts', 'js']
}
```

And we run the tests!

![image-20191115194956149](/assets/images/articles/migrating-to-typescript/image-20191115194956149.png)

## Conclusion

If you want to see all the code that I migrated checkout this [pull request](https://github.com/cesalberca/advanced-javascript-patterns/pull/8/files). If you still have some doubts you can check this other [Spanish article I wrote](https://www.adictosaltrabajo.com/2018/08/01/typescript-vs-javascript/).

And now _what_? Well, you'll see the great advantages that TypeScript provides us like fewer bugs, be able to make a simple refactor as renaming a symbol, or a program that has a living documentation. This and many other advantages just by using TypeScript.

Migrating to TypeScript

You want to change [Karma](https://karma-runner.github.io/latest/index.html) in an Angular application to a better test runner like [Jest](https://jestjs.io/)? Then this tutorial is the one you were looking for!



[Jest](https://jestjs.io/) is a test runner created by Facebook based in Node. Is this last bit which makes it so fast compared to Karma, given that you don't need a browser to execute the tests. Even if you launch Karma headless, Jest still beats Karma running the same test suite for up to **3 times**.

So let's begin!

The first step is to execute this command:

```bash
npm uninstall -DE karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter @types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter
```

With this, we will remove the billion dependencies that you need to execute Karma.

Next, we will remove these files: `karma.conf.js` and `src/test.ts` using this command:

```bash
rm ./karma.conf.js ./src/test.ts
```

Now we will delete from `types` the property `jasmine` and we'll remove from the `files` option the property `src/tests.ts` in the `tsconfig.spec.json`. Our file should end up like this:

```json
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["node"]
  },
  "files": ["src/polyfills.ts"],
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}
```

We add to the `tsconfig.json` the following under `compilerOptions`:

```json
{
    ...
    "compilerOptions": {
        "types": ["jest"]
    }
    ...
}
```

We install `jest` and `builder-jest`:

```bash
npm i -DE jest @types/jest @angular-builders/jest
```

Now, in `angular.json` we replace this configuration:

```json
{
  "test": {
    "builder": "@angular-devkit/build-angular:karma",
    "options": {
      "main": "src/test.ts",
      "polyfills": "src/polyfills.ts",
      "tsConfig": "tsconfig.spec.json",
      "karmaConfig": "karma.conf.js",
      "assets": ["src/favicon.ico", "src/assets"],
      "styles": ["src/styles.css"],
      "scripts": []
    }
  }
}
```

with this one:

```json
{
  "test": {
    "builder": "@angular-builders/jest:run"
  }
}
```

Lastly, we add inside `tsconfig.spec.json` in the option `compilerOptions`: `"esModuleInterop": true`.

We can execute `ng test` and it will run the tests using Jest!

In conclusion, not only did we manage to run our tests faster, we also make the breakpoints launch with a higher success rate, we needed fewer dependencies, fewer configuration, and we'll have features that Jest provides us like [test.each](https://jestjs.io/docs/en/api#1-testeachtable-name-fn-timeout), [snapshot testing](https://jestjs.io/docs/en/snapshot-testing) and [utilidades para mockear](https://jestjs.io/docs/en/mock-functions).

And if you have already started a project, and you want to migrate to Jest I recommend that you checkout out [this codemod](https://github.com/skovhus/jest-codemods) which will migrate most of the code to Jest.

Jest Angular

I’m a self-learning, creative, enthusiast and passionate person. I have a mixed profile, divided between my love for programming, software architecture and design. I truly care about sharing knowledge with my peers, that being as a speaker in different technological events, as a teacher or throughout my social networks.

I believe that Software should be robust yet flexible, and the way to achieve it is to –regardless of the framework– create the right abstractions and apply architectural patterns. Testing is very important to me, the Software we build should be reliable in order to provide the maximum value.

About me

Articles