The UpgradeJS Blog

Benefits of Using a Static Code Analysis Tool in your Next Upgrade Project

My team and I were upgrading an OSS project for research purposes, and this blog was written after the actual upgrade was done. Here we will highlight why the step of inspecting the application with SonarQube-like tool is essential and what we missed because we should have checked it during the upgrade project.

The stack

This is the stack that the application used:

  • docker
  • typescript
  • node.js
  • express.js
  • react.js
  • eslint
  • javascript
  • jest
  • cypress
  • @cypress/code-coverage
  • mwizner/sonarqube:8.9.5-community
  • sonarqube-verify

Statistics from the branch before the upgrade

SonarQube output page with results before upgrade

Before we begin, I want to mention that by using SonarQube opens a new window , you can pretty easily explore the test code coverage data from multiple sources at once.

For example: jest & cypress as a single report. We recently published a blog post on combining code coverage data from jest & cypress tests opens a new window and displaying it in a single report.

In the screenshot you can see that this project had a couple of problems. Let’s look at what it shows and what problems we can eliminate.

Bugs

SonarQube bug error example

From this screenshot, you can see the example of a possible bug in the code. In the following one, you can see the explanation of how we can fix it and why it appears as a bug in the report.

SonarQube bug error explanation

Vulnerabilities

SonarQube vulnerability error example

Here you can see the vulnerability resulting from the outdated usage of the Node.js built-in library.

SonarQube vulnerability error explanation

SonarQube is a great tool to check your code for known vulnerabilities. Another great feature is that it shows you possible ways to resolve the problem.

Security Hotspots

If you are wondering how smart this tool is, here is a great example:

SonarQube security error example with explanation

As you can see, we have a function that creates a string based on some calculations and returns it. SonarQube identifies it as a function that produces an encrypted version of some data, and it is unhappy with the use of the Math.random method for generating a pseudo-random number. That is precisely what the function is doing here.

Code Smells

Code smells are issues based on best practices and writing maintainable code. You can decide to ignore these issues if your team disagrees with it.

Let’s consider two examples from this particular report. Here is a typical example:

SonarQube code smells error example

As shown in this screenshot, the approach to build this validation could be refactored to make it easier to read and understand. SonarQube provides reasonable suggestions to improve our code readability and maintainability.

SonarQube code smells error explanation

This explanation sounds perfect to me :)

But let’s take a look at what is not so straightforward, at least to me:

SonarQube code smells immediately return error example

The suggestion is the following:

SonarQube code smells immediately return error explanation

If you don’t want these issues to appear in your SonarQube report, you have several options to avoid inspection in particular places.

To ignore code blocks you can use this construction:

 // BEGIN-NOSCAN
const someTrickyFunction = () => {
  // ...
}
 // END-NOSCAN

and to skip lines, there is a single-line construction:

// NOSONAR
const unusedVariable = 0;

More options can be found here opens a new window .

Duplication

This feature allows you to keep your codebase as simple and small as possible.

It can show opportunities for you to refactor your project and simplify it by moving duplicated lines of code to separate functions that will be reused later.

Especially when it finds a method that isn’t covered by tests and has duplicates, this is an excellent opportunity for you to significantly improve your code by moving it into a separate function and covering that function with tests at the same time. This can even lead to creating standalone components, as you can figure out from the following screenshot.

SonarQube line duplications error example

That’s it for the initial SonarQube report. Let’s move forward to take a look at what SonarQube reports after our upgrade.

Statistics from the branch after the upgrade

SonarQube output page with results before upgrade

As you can see, the picture is not what we expected it to be. We have definitely made some great improvements to this codebase, but it still has a lot of opportunities for improvement.

Thanks to SonarQube we can keep track of the problems and gaps we have in our application.

Duplication

Thanks to the original report, we were able to fix the Duplication issues during the upgrade of the app, and now this section shows no duplication issues.

Conclusion

The most exciting thing is that you can access many features shown in these reports right from your IDE - SonarLint is your solution. It will analyze your project files on the fly, suggesting improvements and flagging vulnerabilities in your code.

SonarQube is an excellent tool to add to your tool belt, it helps you keep your project up to date without vulnerabilities, duplication, and bugs!