DPS909 Blog - Lab 7: Static Analysis Tools
Published: 2022-11-04 00:28:38

For lab 7 in my open-source course (DPS909), we were asked to implement static analysis tools into our [static site generator (SSG)](https://github.com/alexsam29/ssg-cli-tool).

Static analysis tools help us to maintain quality in the source code by fixing common coding errors and formatting the code to make it much more readable.

## Source Code Formatter
For the source code formatter, I chose to use [Prettier](https://prettier.io/). Prettier is an opinionated code formatter that can be integrated into most of the popular editors/IDEs. I chose this because Prettier works well with JavaScript, which is the language I use for my SSG. I am also familiar with Prettier as I have used the Visual Studio Code extension before.

### Project Setup
To setup Prettier in my project, I followed the [npm installation guide](https://prettier.io/docs/en/install.html) on the website. To summarize, I ran a npm command (`npm install --save-dev --save-exact prettier`) in the terminal to install Prettier packages in the project. Then I created config(`.prettierrc.json`) and ignore(`.prettierignore`) files to let the editor know the project uses Prettier and to let it know what files to ignore. Once the packages are installed and the config and ignore files created, you can run `npx prettier --write .` on the command line to format all files in the project.

### Editor Setup
I use Visual Studio code as my editor of choice.  Prettier offers a VS Code extension that you can download to make using Prettier easier. I downloaded the extension from the extensions sidebar. Prettier docs also has a [editor integration guide](https://prettier.io/docs/en/editors.html) showing how to integrate Prettier into other editors/IDEs.

### Git Hooks
I also installed Git Hooks to make sure that all commits are formatted properly. Again, I followed the same installation guide and ran the following commands to install packages:
```
npm install --save-dev husky lint-staged
npx husky install
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npx lint-staged"
```
Then I added this to my `package.json` file:
```
{
  "lint-staged": {
    "**/*": "prettier --write --ignore-unknown"
  }
}
```
Now, all commits will be formatted properly.

## Linter
For the linter of choice, I decided to use [ESLint](https://eslint.org/). I chose ESLint for the same reason as Prettier, I already had experience using the VS Code extension and it works for JavaScript.

### Project Setup
To setup ESLint in my project, the process was very similar to installing Prettier. I followed the [installation guide](https://eslint.org/docs/latest/user-guide/getting-started) on the website. I first used this command, `npm init @eslint/config` to install packages and create a config file (`.eslintrc.js`) that will contain rules used to check the code. Once this is done, you can then run `npx eslint yourfile.js` to check and fix errors on that specific file.

After installing ESLint, I also had to install `eslint-config-prettier` to make sure ESLint and Prettier work well together. This turns off all ESLint rules that are unnecessary or might conflict with Prettier. I followed this [installation guide](https://github.com/prettier/eslint-config-prettier#installation) to install it.

### Editor Setup
Much like Prettier, ESLint can also be integrated into the editor. Since I use Visual Studio Code there is an extension that is available for download which will make running ESLint easier. For other editors, this [editor integration guide](https://eslint.org/docs/latest/user-guide/integrations) on the website will show you how to integrate ESLint with most of the popular editors.

## Source Code Changes
Running Prettier on my source code didn't change a whole a lot. The main thing that changed was a lot of spacing issues. Indenting was reduced to make more code visible at once without having to scroll horizontally.

ESLint made a lot of changes, mainly to variable declarations. I defaulted to using `var` to declare variables, however, ESLint changed my declarations to use `let` instead to help reduce the chance of errors as described [here](https://eslint.org/docs/latest/rules/no-var). It also changed variables that were not reassigned to use `const` instead of `var`. This is because it helps the reader to understand that the variable is never reassigned and improves maintainability as described [here](https://eslint.org/docs/latest/rules/prefer-const).

## Conclusion
This lab showed me that you can add source code formatting and error checking directly to projects.  Before I had used extensions for this purpose and never directly implemented it by installing it into the project. Now because of this lab, I know how to directly implement static analysis tools into future projects to make sure my code is readable and follows good coding practices.

Here are all the changes made to my project: https://github.com/alexsam29/ssg-cli-tool/commit/bcde670fb80c102fcdd37d4febdd39b99b4b7ca1