SonarQube

React Native and Expo checks, inside SonarQube

SonarQube reads your JavaScript, Kotlin and Swift, but it does not know that Xcode 27 will not launch an app without UIScene, that Google Play hides apps with an old target SDK, or that a library stops the iOS build on React Native 0.87. NativeKeel does, and it can hand those findings to SonarQube, so they sit in the same project, the same dashboard and the same quality gate as everything else.

Two lines in your pipeline

npx nativekeel --sonar nativekeel-sonar.json --fail-on never
sonar-scanner -Dsonar.externalIssuesReportPaths=nativekeel-sonar.json

Run both from the folder SonarQube analyzes (sonar.projectBaseDir): file paths in the report are written relative to it. Keep package.json, ios/ and android/ inside sonar.sources, because SonarQube attaches each issue to a file it indexed.

With GitHub Actions

steps:
  - uses: actions/checkout@v5
  - uses: AlicanAkyol/nativekeel@v0
    with:
      sonar: nativekeel-sonar.json
      fail-on: never        # let the SonarQube quality gate decide
  - uses: SonarSource/sonarqube-scan-action@v8
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
    with:
      args: -Dsonar.externalIssuesReportPaths=nativekeel-sonar.json

How findings map

Each issue points to the file and line NativeKeel found, or to the package.json line that declares the package. Rules show up as external_nativekeel:<check>. Accepted findings are managed in NativeKeel's .nativekeel.json (each with a reason), since SonarQube does not manage external rules in quality profiles.

Why it fits teams already on SonarQube

• No new dashboard to watch. Mobile findings live where your team already looks.
• Your code stays where it is. NativeKeel runs in your pipeline and writes a JSON file; only package names go to npm and React Native Directory (--offline sends nothing).
• Free and MIT licensed, no account, no dependencies.