The UpgradeJS Blog

Welcome to the third installment in our series of blog posts on SonarQube!

In the first chapter, we guided you through the basic configuration of a local SonarQube instance, while in the second chapter, we demonstrated how to set up SonarQube and your application to display unit and end-to-end test data.

In this third chapter, we’ll explore the integration of SonarLint with WebStorm IDE to help you catch issues early on in the development process.

SonarQube is an open-source platform developed by SonarSource that provides continuous inspection of code quality through static code analysis.

There are two ways to set up SonarQube analysis - you can select from the cloud solution (sonarcloud) or install a SonarQube instance on your machine or a remote server. In the first chapter we set up a local SonarQube instance and ran the analysis for a simple JavaScript application

In this chapter, we will continue to work with the same application and add more features to it.

SonarQube is an open-source platform developed by SonarSource that provides continuous inspection of code quality through static code analysis.

There are two ways to set up SonarQube analysis - you can select from the cloud solution (sonarcloud) or install a SonarQube instance on your machine or a remote server. Today we will cover setting up a local SonarQube instance to analyze your code.

As the upgrade team, one of our most significant challenges is the initial setup of each project, as many of the tools we utilize for inspection need distinct and customized configurations. This is due to the countless methods in which JavaScript/TypeScript projects can be constructed.

In today’s demonstration, we will introduce you to our new open source project called plugin-preloader and show you how you can use it to simplify your workflow if you encounter similar issues as we do.

In a previous post, I covered some useful static code analysis tools for getting a sense of the size of a Node.js application, as well as the health of its external dependencies. This post will continue to look at static analysis tools, with a focus on understanding and visualizing the application’s architecture, patterns (good and bad), and internal dependencies.

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.

Whether you’re joining a team to work on an existing application, or just want to get a better idea of the status of the application you’ve been working on for a while, static analysis tools can help.

These tools can provide you with a better sense of the size and scope of your application, its architecture, and provide insight into areas of importance, high complexity, low test coverage or poor testability, and more.

Of course, these tools are no substitute for human review and team discussion, but they certainly can be used to expedite that process.

Contributing to open source projects is a big part of our philosophy at OmbuLabs. It’s even written into our values. Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.

There are some really great guides for starting a new open source projects, yet when it comes to dealing with a possibly abandoned, unmaintained project, there is no definitive guide for users, contributors, or maintainers.

I hope that this can be a useful guide for our community.

Problem

When do you declare that an open source project has been abandoned? How many days have to go by until you start maintaining your own fork? What’s the standard for communicating with maintainers, contributors, and users? How do you avoid n competing OSS forks of popular projects? How do you avoid duplicated work by people who want to maintain popular, but unmaintained OSS projects? What’s the best way to find that one fork everybody is using?