Frontend Code Quality: SonarJS
Status: Decided
Assignee: Moritz Adelsberger
Problem
PermaplanT frontend code quality is enforced via ESLint, Prettier, TypeScript, and Vitest in CI. The question is whether adding SonarQube or SonarJS provides meaningful additional quality assurance.
Constraints
- New infrastructure must justify its operational cost (provisioning, maintenance, monitoring).
- Quality tooling must integrate into the existing Jenkins CI pipeline.
- The solution must not introduce external service dependencies unless clearly beneficial.
Assumptions
- The existing toolchain (ESLint +
@typescript-eslint/recommended,eslint:recommended, Prettier, tsc, Vitest, E2E tests) already covers the majority of common JS/TS quality issues. - A SonarQube server would require a dedicated host, ongoing maintenance, and monitoring.
- SonarCloud is free for open source but introduces a third-party service dependency.
Solutions
Alternative A: SonarQube server
Self-hosted SonarQube instance on a new or existing host, integrated into Jenkins via the SonarQube plugin.
Violates Constraint 1: requires provisioning, maintaining, and monitoring a new service for marginal gain over the existing toolchain.
Alternative B: SonarCloud
Free for open source projects. Provides PR decoration and quality gate history without self-hosting.
Violates Constraint 3: introduces an external service dependency. Adds little over the existing toolchain given the coverage already provided by ESLint with TypeScript rules.
Alternative C: eslint-plugin-sonarjs
The SonarJS rules are available as a standalone ESLint plugin (eslint-plugin-sonarjs).
This runs within the existing npm run lint step in CI — no new infrastructure, no external service.
Adds rules not present in @typescript-eslint/recommended or eslint:recommended:
cognitive complexity, bug-prone collection patterns, duplicate string literals, ignored return values.
Decision
Use Alternative C: add eslint-plugin-sonarjs to the frontend ESLint config.
No SonarQube server or SonarCloud integration.
Rationale
The existing toolchain is already strong. A full SonarQube deployment adds infrastructure overhead
that is not justified by the incremental quality gain. eslint-plugin-sonarjs delivers the
most relevant SonarJS rules within the existing CI lint step at zero infrastructure cost.
Implications
- No new host or service to provision or monitor.
- Add
eslint-plugin-sonarjstofrontend/dev dependencies and extendeslint.config.js. - Fix any newly surfaced warnings/errors before enabling in CI.
Related Decisions
Notes
- Analysis done in infrastructure issue #376.