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.

Static Analysis Testing JavaScript Applications

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

Instructor: [00:00] For this one, I'm going to go to my preferences. I'm going to disable our `formatOnSave` option here, so I can show you something that might be a scenario you come across.

[00:10] I'm going to add a couple of spaces here. We're going to use some formatting nightmare stuff here. Then we're going to look at our `git status`. That's our file we're going to change, `git commit`, all that stuff with bad formatting.

![bad format example](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1574890642/transcript-images/javascript-auto-format-all-files-and-validate-relevant-files-in-a-precommit-script-with-lint-staged-bad-formatting-example.jpg)

[00:22] Let's just say that I don't have the `prettier` plugin installed on my editor. I'm using Emacs, or something. I haven't figured it, or whatever.

[00:31] This would be a really frustrating situation for them, because every time that they commit code, they're going to have to run this validate script.

[00:38] They find out, "Oh, that's right. I forgot to format this file," which is super annoying. I `npm run format` and blah, blah, blah, blah, blah.

[00:45] They don't want to do that, right? It would be really nice if we could automatically format it.

[00:50] It's not going to change the behavior of the code, so let's automatically format it for them as they're committing the code. They don't have to even worry about installing the plugin if they don't want to.

[00:58] That's what we're going to do a tool called `lint-staged`. We'll install it as a dev dependency, `lint-staged`. We'll go to our `package.json` here, we'll verify that, gets added to our dependency list here.

### Terminal Input
```
npm install --save-dev lint-staged
```

[01:14] Now at `lint-staged`, we're going to create a configuration file for that, `.lintstagedrc`.

[01:22] For this configuration, we're going to say, "Hey. Any files that you're processing in this commit, if they match `*.+`, one of these `js` or `ts` or `tsx`, I want to run the following scripts, `"eslint"`."

### .lintstagedrc
```
{
  "*.+(js|ts|tsx)": [
    "eslint"
  ]
}
```

[01:35] It's going to run `eslint` across `that.js` and `thisone.js`, or `.ts` or whatever, that's how it's going to run it. We just specify `eslint` and `lint-staged` will forward on those files to this script that we've passed.

[01:50] We're going to pass it to `eslint`. We're also going to handle formatting for all files in our project that we support.

[01:57] I'm actually just going go to our `package.json`. We'll copy this glob right here, because that's the one that we're going to want to use in here. I'll just copy that.

[02:07] For any files that are being committed that matched this, we're going to run it through `prettier --write` and then `git add` because it's going to be changed. We want to add the changes back to git, so that it's committed with those changes.

### .lintstagedrc
```
{
  "*.+(js|ts|tsx)": [
    "eslint"
  ],
  "**/*.+(js|json|ts|tsx)": [
    "prettier --write",
    "git add"
  ]
}
```

[02:21] We'll save this and then we'll configure `lint-staged` to be run on commit. What is running on commit? Well, it is Husky. Husky is in-charge of running some scripts on commit. We're going to instead of running the `validate` script, we're actually going to run `lint-staged`.

### .huskyrc
```
{
  "hooks": {
    "pre-commit": "lint-staged"
  }
}
```

[02:37] `lint-staged` is taking care of our linting of the files that are being committed and it's taking care of our formatting, but it's actually not taking care of our type-checking or our build. We're going to want to keep those.

[02:49] Run `npm run check-types`. Then we'll run `lint-staged`, and then we can run `npm run build`. With that, now, I'll go ahead and `add` all of this stuff, `git commit 'stuff'`.

### .huskyrc
```
{
  "hooks": {
    "pre-commit": "npm run check-types && lint-staged && npm run build"
  }
}
```

[03:01] This is going to run our `type-checking` first, then it runs `lint-staged`, which is that fancy thing. Then it runs our build to make sure that all of that stuff is still happening.

[03:10] The cool thing about `lint-staged` is that it's only running across the files that are being changed. We've configured it to add files back if they're being changed by `prettier`.

### Terminal
![lint-staged feature](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1574890637/transcript-images/javascript-auto-format-all-files-and-validate-relevant-files-in-a-precommit-script-with-lint-staged-lint-staged-feature.jpg)

[03:20] We can go take a look at our `typescript-example.js`. Indeed, that has been reformatted for us automatically.

[03:26] `lint-staged` is really cool because it can even manage patch changes. If you're only committing part of the file, it will only update the part of the file that's actually being changed, which is pretty rad.

[03:36] In review, to make all this work, we're going to go to our `package.json`, add `lint-staged` to our dev dependencies. We'll go to our Husky and update that `pre-commit` to run `lint-staged`, which is handling our linting and our formatting. We're just going to have this runner typing and our build.

[03:53] In `lint-staged`, we configure any JavaScript, TypeScript, or TSX file to run through ESLint, and any JS, JSON, TS, or TSX file to run through `prettier` with the `--write` flag and to `git add` so that those updates git committed with the commit that's happening.

[04:11] That improves the experience of everybody using the project so they don't necessarily have to have `prettier` configured for their editor.


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

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.

Make ESLint Support TypeScript Files

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

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.

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

Transcript

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