SonarJS Rules for Frontend Assets in .NET Repositories

Trigger On

• the repo already uses SonarQube, SonarCloud, or eslint-plugin-sonarjs
• the user asks for frontend code smells, cognitive complexity limits, or deeper bug-risk rules beyond base ESLint
• maintainability and reliability findings on JS or TS code should become a review or CI gate

Workflow

1. Decide the execution path first:

- local developer loop through eslint-plugin-sonarjs - server-side analysis through an already adopted SonarQube or SonarCloud pipeline

1. For local work, treat SonarJS as an ESLint extension rather than a standalone CLI.
2. Keep the first rollout narrow:

- bug-prone rules - cognitive complexity - duplicated branching or suspicious control flow

1. Add rules to the existing ESLint command instead of inventing a parallel local lint entrypoint.
2. If the repo already has SonarQube or SonarCloud, align local rule expectations with the server gate instead of maintaining two conflicting policies.
3. Fix code or phase rules deliberately; do not hide the first rollout behind broad disables.
4. Document licensing or hosting caveats before making Sonar-based tooling the default quality gate.

Deliver

• explicit SonarJS-derived rule ownership
• a clear split between local ESLint-based use and any existing server-side Sonar pipeline
• documented rollout scope and caveats

Validate

• local developer commands still use the repo's standard ESLint entrypoint
• Sonar-based rules are not treated as a standalone local CLI when none exists
• licensing or hosting caveats are documented before broad adoption
• findings are actionable and phased instead of silently suppressed

Related skills

Related agents