Linting an Existing Application: 3 Key Things I Learned
Tags: react, typescript, beginners
Published: 2019-09-08 21:43:31

I’m here to write on something I’m really proud of doing at work: linting an un-linted production codebase! For one of my onboarding tickets, I set up TSLint in the build of a React project - meaning code with linting errors can’t be merged to master. Linting would be 100% necessary! Yay! What this also meant for me was fixing a ton of existing linting errors.

![cleaning gif](https://media.giphy.com/media/LLR3cBvqxpamY/giphy.gif)

I had never linted my personal projects, so this process was new to me. I also wasn't too familiar with the codebase and it used TypeScript, which I don’t know. #challengeaccepted. Throughout the linting process, I thought a lot about linting best practices and researched many of the TSLint error messages to understand what was wrong with the code. Here are 3 key things I learned while working on this project:

# Enable TSLint to Auto Fix Errors
Some of the linting errors were easy fixes such as missing semicolons, trailing whitespaces at the end of a line, consecutive blank lines, etc. Though easy to fix, it would have been time consuming to fix them manually. There’s always a better way, and I learned that you can enable your IDE to automatically fix eligible linting errors.

Here’s how I set it up in VS Code:
 * Download the [TSLint extension] (https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-tslint-plugin)
 * In VS Code's *settings.json* file, add:
```
”editor.codeActionsOnSave”: { “source.fixAll.tslint”: true }
```
###### (`Prefences` -> `Settings` -> search for "settings.json" -> select `Edit in settings.json`)

To get the automatic TSLint fixes, I went directly to the file with linting errors and just saved it; I didn’t need to make any changes to the file. I preferred this method over running the terminal command `tslint —fix` (which would automatically fix all eligible linting errors across the whole application) since I wanted to get more familiar with the codebase and understand the code in those files. 

Check out [TSLint core rules](https://palantir.github.io/tslint/rules/) to see what linting errors are eligible to be fixed automatically; search for the “Has Fixer” flag.

# Silence *Some* Errors
For some of the errors, I wondered about their severity and *what linting errors are fine to ignore?* I searched for [articles](http://help.embold.io/tslint-high/) on this topic and asked around and ultimately learned this is subjective. I started looking at other React projects that used Typescript at the company and compared *tslint.json* files (where linting rules can be silenced) to see if there was a standard practice. Here's an example of how to silence TSLint rules in *tslint.json*:
```
 "rules": {
      "object-literal-key-quotes": false,
      "no-any": false
}
```

Silencing a rule in the *tslint.json* file ignores the rule overall but you can also silence a single instance of a linting error. The latter is a great alternative if generally you think the TSLint rule is important to address but want to make an exception for a certain line of code. Perhaps there’s a reason to keep the line of code the same or perhaps TSLint incorrectly flagged there was an error (this happened on a few occasions). To ignore an instance of a linting error, place this above the flagged line of code: 
`// tslint:disable-next-line: <name-of-linting-rule>`
```
// tslint:disable-next-line: react-unused-props-and-state
```

# Carefully Review Lint Fixes
I used Version Control in VS Code to quickly and easily review the changes made, especially if they were from automatic fixes. I was concerned about over-linting, breaking a feature, or introducing a new bug, so as I fixed linting errors I tested that the application was still working as expected. Through linting the application slowly, I also noticed a few instances where TSLint mistakenly flagged an error. For example, a few lines were flagged with `react-unused-props-and-state` but the props *were* being used in the file.

![suspicious gif](https://media.giphy.com/media/lxfXcVFaE42By/giphy.gif)

For me, addressing linting errors in small batches and in a controlled manner was the best way to make sure I was linting properly and to review and test changes.

I learned a lot through this experience and am happy that I contributed in an important way to ensure consistent coding style and improve the development process for my teammates.

I’ll end this post with a linting playlist. Fixing linting errors can take a while and listening to music helps keep your mood 🌞🌞🌞.

{% spotify spotify:playlist:1yZdw9xRtSwCQF0fL8VrJV %}