ESLint does not have support for TypeScript out of the box, but luckily adding support for TypeScript is straightforward thanks to the [TypeScript-ESLint](https://typescript-eslint.io/) project. And now that we have TypeScript, there are a lot of rules that we don’t need ESLint to bother checking because TypeScript will prevent those problems in the first place! Let’s get these two tools integrated.

Static Analysis Testing JavaScript Applications

Make ESLint Support TypeScript Files

Instructor: [00:00] Right now, we have ESLint configured to run across all of the JavaScript files in our project, but it doesn't run across the TypeScript files. If I run `npm run lint`, I'm not going to get any linting errors in here at all.

### Terminal Input
```
npm run lint
```

[00:13] TypeScript makes lots of rules that ESLint has unnecessary because TypeScript is great that way, but there are some rules that ESLint has that would be useful in TypeScript. Right now, we're getting this red underline because ESLint in VS Code is trying to parse this file, but it can't because it's written in TypeScript.

### typescript-example.js
![parsing example error](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1574890639/transcript-images/javascript-make-eslint-support-typescript-files-error-example.jpg)

[00:31] We need to enable ESLint to be able to parse this TypeScript file. To do that, I'm going to `npm install`, and save these as devDependencies, `@typescript-eslint/eslint-plugin`, and `@typescript-eslint/parser`. With these two installed, they're going to go in my devDependencies right here. I can now configure ESLint.

### Terminal Input
```
npm install --save-dev @typescript-eslint/eslint-plugin @typescript-eslint/parser
```

[00:56] The first thing I'm going to do here is in my `"lint"` script, I want to make sure that ESLint runs across TypeScript files, so I'm going to add an `--ext` for extension `.js`, `.ts`, and `.tsx`. Now when I run `npm run lint`, it's going to run across my TypeScript files. Of course, it still isn't configured to parse TypeScript files properly, so let's go ahead and do that next.

### package.json
```json
{
  ...
  "scripts": {
     "build": "babel src --extensions .js,.ts,.tsx --out-dir dist",
     "lint": "eslint —-ignore-path .gitignore —ext .js,.ts,.tsx .",
     "check-types": "tsc",
     "prettier": "prettier --ignore-path .gitignore --write \"**/*.+(js|json|ts|tsx)\"",
     "format": "npm run prettier -- --write",
     "check-format": "npm run prettier -- --list-different",
     "validate": "npm run check-types && npm run check-format && npm run lint && npm run build"
   },
  ...
}
```

[01:21] Now we're running ESLint across multiple files, not just TypeScript files and so we're going to keep the same configuration, but I want to override this configuration for TypeScript files. We're going to use ESLint's overrides configuration property. For `"files"` which matched this glob of `**/*.+(ts|tsx)`. For any TypeScript files, I want this configuration to be applied.

### .eslintrc
```json
{
  ...
  "overrides": [
    {
      "files": "**/*.+(ts|tsx)"
    }
  ]
}
```

[01:52] We'll set the `"parser"` to be `"@typescript-eslint/parser"`, so the one we just installed. For the `"parserOptions"`, we need to specify where our TypeScript configuration is. That's what the `"project"` property and the `"./tsconfig.json"` pointing to our configuration file.

### .eslintrc
```json
{
  ...
  "overrides": [
    {
      "files": "**/*.+(ts|tsx)",
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "project": "./tsconfig.json"
      }
    }
  ]
}
```

[02:13] Then, we want to specify some plugins, which have some custom rules for us that are specific to TypeScript. We're going to have `@typescript-eslint/eslint-plugin`. This adds a couple additional rules that we can configure. We're not going to configure those manually, instead, we're going to extend these `"extends"` a couple of pre-built configurations.

[02:35] There are `"plugin"` configurations and the plugin is going to be from `@typescript-eslint/eslint-recommended`. We'll also have a plugin `@typescript-eslint/recommended`. What this one does is it disables some rules that are not necessary because we're using TypeScript. I'll show an example of that really quick.

### .eslintrc
```json
{
  ...
  "overrides": [
    {
      "files": "**/*.+(ts|tsx)",
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "project": "./tsconfig.json"
      },
      "plugins": ["@typescript-eslint/eslint-plugin"],
      "extends": [
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended"
      ]
    }
  ]
}
```

[03:01] If we go to our example here, you remember how this was a typo and this was breaking the valid type of rule. If we have that same problem in a TypeScript file, we're going to get two warnings. We'll get one from ESLint, and we'll also get one from TypeScript because TypeScript has a much better picture of what our code is supposed to be.

### typescript-example.js
![typescript eslint error example](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1574890643/transcript-images/javascript-make-eslint-support-typescript-files-error-ts-eslint.jpg)

[03:23] It's doing some of the same linting capabilities by itself. That's why it's useful to enable this particular `"plugin"` configuration set because it disables some of those rules that TypeScript renders unnecessary. This rule set is some specific rules from the TypeScript ESLint plugin that are useful for TypeScript files that are sometimes specific to the way that you're writing your interface, for example.

[03:48] Let's clean that up. Then we'll run `npm run lint`. That's going to run linting across all of our files. We are still getting some ESLint errors here. It's saying it's expecting a semicolon from the rule `@typescript-eslint/member-delimiter-style`.

[04:05] This is a style specific rule. It doesn't have any bearing on whether your program worked properly or not. It's just saying that you should probably have a `;` here, but it's not necessary. It conflicts with my Prettier configuration where if I save that, it removes those semicolons.

### typescript-example.js
```js
interface User {
  name: {
    first: string
    middle: string
    last: string
  }
}
```

[04:21] To disable that, we already have installed in this project `"eslint-config-prettier"`. `"eslint-config-prettier"` is able to disable the rules from `"typescript-eslint"` that are not necessary.

[04:33] We're going to add, as our final extend, `"eslint-config-prettier/@typescript-eslint"`. With that, if we go to our TypeScript file, we're no longer getting those warnings. We can npm run lint, and there are no errors there either.

### .eslintrc
```json
{
  ...
  "overrides": [
    {
      "files": "**/*.+(ts|tsx)",
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "project": "./tsconfig.json"
      },
      "plugins": ["@typescript-eslint/eslint-plugin"],
      "extends": [
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended",
        "eslint-config-prettier/@typescript-eslint"
      ]
    }
  ]
}
```

[04:49] In review, to make this work, we added `"@typescript-eslint/parser"`, and `"@typescript-eslint/eslint-plugin"` to our `package.json`. Then we updated our ESLint configuration to use the `"overrides"` property so that all files matching `.ts` and `.tsx` use the `"@typescript-eslint/parser"` pointing to our custom `"./tsconfig.json"`.

[05:08] We added some TypeScript specific ESLint rules so that we could extend these built-in configurations and utilize some of those rules that typescript-eslint provides to us. Then we finally extended the `"eslint-config-prettier"`, so we disable all the rules that typescript-eslint adds that we don't necessarily need because we're using Prettier.


There are a ton of ways your application can break. One of the most common sources of bugs is related to typos and incorrect types. Passing a string to a function that expects a number, or falling prey to a common typo in a logical statement are silly mistakes that should never be made, but this happens all the time.

We could write a comprehensive suite of automated tests for our entire codebase to make certain mistakes like this never happen, but that would likely be too much work and slow development down to be worth the benefit. Luckily for us, there are tools like ESLint, TypeScript, Prettier, and more which we can use to satisfy a whole category of testing with a great developer experience.

Intro to Static Analysis Testing JavaScript Applications

The static code analysis and linting tool ESLint is the de-facto standard for linting JavaScript projects. In this lesson we’ll see how to install, run, and configure it for your preferences.

Lint JavaScript by Configuring and Running ESLint

Whatever editor you use, chances are there’s probably some plugin or extension you can use to integrate ESLint and your editor to get a nice in-editor experience using ESLint so you don’t have to run the ESLint script to check your code and instead can identify issues as you’re writing and editing your code. Let’s take a look at what you can do with [the ESLint Extension for VSCode](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint).

Use the ESLint Extension for VSCode

ESLint has [a TON of rules](https://eslint.org/docs/rules/) you can configure for your project. But who has time to do all that? This is why ESLint has an extends configuration which you can use to base your own configuration off of other configurations. Let’s add all of ESLint’s built-in recommended rules to our project and override just the ones we want to change.

Use pre-built ESLint Configuration using extends

Let’s add an npm script called lint so we can run ESLint whenever we want with the proper command line flags.

Run ESLint with npm Scripts

The code formatting tool [prettier](https://prettier.io/) can help you avoid a lot of useless time spent formatting code and arguing about code formatting with your co-workers. It can also help you catch subtle issues with your code that you may not notice otherwise. In this lesson we’ll learn how to install and run prettier.

Format Code by Installing and Running Prettier

1. Prettier is a pretty opinionated tool, but it does allow for some customization. In this lesson we’ll check out [the prettier playground](https://prettier.io/playground/) and see what options we want to enable in our project’s `.prettierrc` file. 
2. After adding in our custom configuration, we’ll create a `.prettierignore` file so that you can avoid formatting any files generated within the project such as `node_modules` or a `build` folder.

Configure Prettier

Running prettier manually is great, but it’d be even better if we could just run prettier anytime we save our file. Whatever editor you use, there’s likely a plugin or extension for it to integrate with prettier. Let’s try out [the Prettier Extension for VSCode](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode).

Use the Prettier Extension for VSCode

Because prettier can automatically fix a lot of stylistic issues in our codebase, it’s not necessary to have eslint check for those and it can actually be kind of annoying if it does. So let’s see how we can use eslint-config-prettier to disable all rules that are made irrelevant thanks to prettier.

Disable Unnecessary ESLint Stylistic Rules with eslint-config-prettier

1. You can’t force everyone on your project to use the prettier integration for their editor, so let’s add a validation script to verify that prettier has been run on all project files.
2. Fortunately for us, Prettier accepts a `--list-different` flag that you can use that will throw an error when code is not up to the standard of your project.

Validate All Files are Properly Formatted with Prettier

ESLint can check for a lot of things, but it’s not a great tool for checking the types of variables that flow through your application. For this you’ll need a type-checking tool like [Flow](https://flow.org/) or [TypeScript](https://www.typescriptlang.org/). Let’s see how we can configure our project to work with TypeScript.

Avoid Common Errors by Installing and Configuring TypeScript

We have a few checks we’ll run in continuous integration when someone opens a pull request, but it’d be even better if we could run some of those checks before they even commit their code so they can fix it right away rather than waiting for CI to run. Let’s use husky’s precommit script to run our validation.

Validate Code in a pre-commit git Hook with husky

Rather than failing when a developer has failed to format their files or run linting on all the files in the project on every commit, it would be even better to just automatically format the files on commit and only check the relevant files with eslint. Let’s use lint-staged to run scripts on the files that are going to be committed as part of our precommit hook.

Auto-format All Files and Validate Relevant Files in a precommit Script with lint-staged

I use npm scripts a lot, and that validate script is a great way to bring everything together. But with the way these tools work, we can run them all at the same time and things will work just as well. This will speed up our script runtime a lot, so let’s use [npm-run-all](https://npm.im/npm-run-all) to make that happen.

Make ESLint Support TypeScript Files

Transcript

Make ESLint Support TypeScript Files