Improve Frontend Code Quality with Tools — SonarQube

Our backend teams adopted SonarQube; I followed suit on the frontend. Along the way I corrected some misconceptions — notes below.

SonarQube vs. ESLint

ESLint is familiar to frontend devs; it enforces style and some best practices. With unit tests, I once thought Sonar wasn’t necessary. In practice they differ:

1. ESLint focuses on style and some patterns; you fix findings manually or via autofix.
2. Sonar goes beyond style to detect code smells and potential bugs, tracks trends over time, and gives quality gates.

They’re complementary — especially useful for large teams with varied experience.

Setup

Here’s a minimal setup:

1. SonarQube Web创建新项目
2. 项目下增加sonar-project.properties，按需配置，
3. GitLab CI增加如下PipeLine

sonar:
  stage: sonar_scanner
  image: "nexus.abc.cn/sonarsource/sonar-scanner-cli:4"
  allow_failure: true
  services:
    - docker:stable-dind
  script:
    - sonar-scanner -Dsonar.projectKey=$SONAR_QUBE_PROJECT_KEY
  only:
    - /^sprint/

This triggers a Sonar scan on branches prefixed with sprint. Adjust rules and conditions over time.

Final Thoughts

Humans make mistakes — tools like Sonar complement reviews and tests by continuously surfacing potential issues.

References

• https://stackshare.io/stackups/eslint-vs-sonarqube