Linting an Existing Application: 3 Key Things I Learned

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.

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
• 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 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 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.

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 🌞🌞🌞.

Comments

[Mark Roeling]

Having a ts code base ourselves, and officially there is no official coding standard, we looked at Prettier.io.
It turned out that recently (?) the separate rules can be edited. Also, tslint is deprecated, and eslint is the way to go.

These things combined made us go for eslint, with the addition of some plugins.

    parser: '@typescript-eslint/parser',  // Specifies the ESLint parser
    extends: [
        'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from the @typescript-eslint/eslint-plugin
        'prettier/@typescript-eslint',  // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
        // 'plugin:prettier/recommended',  // Enables eslint-plugin-prettier and displays prettier errors as ESLint errors. Make sure this is always the last configuration in the extends array.
    ]

The recommended Prettier settings we disabled, since that colided with some of the settings we wanted to set. In the rules section we added some 20 more settings.

The result is a codebase that now is linted on every (Jenkins) build, failing on every warning or error. 100% eslint, 100% phpcs, 100% phpunit coverage, and starting with Cypress for the e2e testing.

Extra +1 for the playlist! :)

[scarlett]

thank you for the info and examples!