dotnet-sonarjs

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

Do Not Use For

• repos that want only a lightweight base lint setup with no extra smell or complexity rules
• teams that reject SonarQube, SonarCloud, or source-available SonarJS-derived tooling as a default gate
• cases where the problem is runtime page quality rather than source-level maintainability

Inputs

• the nearest AGENTS.md
• package.json
• existing ESLint config
• any SonarQube, SonarCloud, or scanner config already present in CI

flowchart LR
  A["Need Sonar-style checks in a .NET repo frontend"] --> B{"Local developer loop or existing server gate?"}
  B -->|Local| C["Install eslint-plugin-sonarjs"]
  C --> D["Run through the normal eslint command"]
  B -->|Existing SonarQube or SonarCloud gate| E["Keep full analysis in the existing scanner pipeline"]
  D --> F["Phase rules and fix code"]
  E --> F

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
2. For local work, treat SonarJS as an ESLint extension rather than a standalone CLI.
3. Keep the first rollout narrow:
   • bug-prone rules
   • cognitive complexity
   • duplicated branching or suspicious control flow
4. Add rules to the existing ESLint command instead of inventing a parallel local lint entrypoint.
5. If the repo already has SonarQube or SonarCloud, align local rule expectations with the server gate instead of maintaining two conflicting policies.
6. Fix code or phase rules deliberately; do not hide the first rollout behind broad disables.
7. Document licensing or hosting caveats before making Sonar-based tooling the default quality gate.