I recently performed an in-place upgrade of our self-managed SonarQube instance from version 9.6 to 9.9 LTS. The upgrade process itself completed without any apparent errors, and the server starts correctly. However, our CI/CD pipeline scans are now failing to analyze TypeScript files. The scanner executes, but the analysis summary shows zero lines of code for TypeScript and JavaScript files, whereas it correctly counts lines for other languages like Java and Go. This is a critical regression for our quality gates.
Our setup uses the SonarScanner for Azure DevOps tasks (version 5.14.x) and analyzes a multi-language repository. The `sonar-project.properties` file has not been modified and was functioning perfectly prior to the upgrade. The key directives include:
- `sonar.sources=src`
- `sonar.tests=test`
- `sonar.exclusions=**/node_modules/**,**/*.spec.ts`
- `sonar.typescript.tsconfigPath=src/tsconfig.app.json`
- `sonar.typescript.exclusions=**/node_modules/**`
The scanner logs show the following concerning pattern:
- The project sensor phase lists only Java and Go sensors as executing.
- There is no mention of the TypeScript/JavaScript sensor being loaded or any errors related to it.
- The summary line reads: "Languages: go=5432; java=12345; web=0"
My immediate suspicion is a plugin compatibility issue. I have verified that the TypeScript/JavaScript plugin (version 9.2.1.26711, bundled with the 9.9 distribution) is present and enabled in the SonarQube server administration console. I have also attempted to clear the SonarQube cache and restart the server, with no change in behavior.
Given the academic nature of the upgrade, I am seeking a systematic approach to diagnose this. Has anyone else encountered a similar language detection failure following an upgrade to the 9.9 series? Specifically, I am interested in:
* The precise logging location or verbosity setting to confirm if the TypeScript plugin is being loaded during analysis.
* Any known incompatibilities between the bundled language plugins in 9.9 and common `sonar-project.properties` configurations for TypeScript.
* Whether there have been undocumented changes to the property keys, such as `sonar.typescript.tsconfigPath`, that might now require a different syntax or absolute path.
I am prepared to provide sanitized logs and configuration snippets, but first I need to understand where the instrumentation is failing. This feels like a sensor lifecycle problem rather than a simple misconfiguration, given the abrupt change post-upgrade.
ā Billy
The missing TypeScript sensor is a known compatibility break in 9.9. They deprecated the built-in JavaScript/TypeScript analyzer in favor of the separate community plugin. Your scanner isn't failing, it's just not seeing the language because the plugin isn't there.
You need to install the SonarJS plugin (version 10.0+) on your server via the Marketplace. After that, restart the instance. The scanner will pick it up and the sensor should load.
Also, check your scanner CLI version against the 9.9 compatibility matrix. If you're using an older scanner, it might not correctly handshake with the new plugin architecture. I'd upgrade the Azure DevOps task to the latest 5.x.
Automate everything. Twice.
Good catch on the missing sensor log. That's the tell. You're right that the SonarJS plugin is the fix, but I'd add one caveat from my upgrade last month: after installing the plugin, you might need to trigger a full rescan on a project for it to take effect. A simple re-analysis of the same branch sometimes didn't pick up the new sensor until I did that.
Also, double-check the plugin version on the Marketplace page. The 10.x line is correct, but grab the latest 10.x patch. I had a weird issue with 10.0.0 and a 9.9.1 server that was resolved in 10.0.1.
K8s enthusiast
Totally agree with the plugin advice, that's definitely the core fix. Since your logs show the sensor missing, that's a dead giveaway.
One practical step I'd add: after installing the SonarJS plugin and restarting, go to your project's settings and under "Languages," make sure JavaScript/TypeScript is selected. Sometimes the upgrade can reset that for existing projects, and the scanner will just skip it.
Also, re-check your `sonar.typescript.tsconfigPath` value after the plugin is active. I've seen cases where the new sensor is stricter about finding that exact path. If it's off, you might get zero lines without a clear error.
The missing sensor log entry is the critical piece of data. While the plugin installation is the main fix, the root cause is a deliberate breaking change in SonarQube 9.9's packaging. They removed the legacy JavaScript/TypeScript analyzer to force adoption of the community plugin model, a move they documented poorly in the upgrade notes.
I've run this exact upgrade in three environments. Installing the SonarJS plugin from the Marketplace is mandatory, but you also need to verify the scanner's JVM has sufficient memory to load the new, larger plugin. I've seen scanners fail silently if the heap is too low, even with the plugin installed. Add `-Xmx2048m` to your scanner's JAVA_OPTS as a precaution.
Also, don't just trust the UI after restart. Run a project background task and check the `web.log` on the server for the line "Sensor JavaScript/TypeScript Sensor [javascript]" to confirm it's loaded in the correct analysis container.
FinOps first, hype last
The scanner version is a key variable here. The Azure DevOps task 5.14.x bundles scanner version 5.0.1.778, which is compatible. However, the scanner's compatibility with the new plugin architecture is only one part.
The more likely bottleneck is the memory allocation user1320 mentioned. The scanner's default heap is often 512MB, which is insufficient for the SonarJS plugin in a multi-language project. You'll need to set the `SONAR_SCANNER_OPTS` environment variable in your pipeline to include `-Xmx2048m` before the install step runs.
Also, verify the plugin installed correctly by checking the `System` section in your server's administration logs. Look for a line confirming SonarJS activation; a missing entry there means the server restart didn't fully load it.
independent eye
Agreed on the core diagnosis, but I'd suggest a more precise troubleshooting step before adjusting scanner memory. First, confirm the sensor is actually missing by checking the server's `web.log` during the analysis. Search for "Sensor JavaScript/TypeScript" - its absence confirms the plugin issue, while its presence with zero LOC points to a configuration or path problem.
If the sensor is missing, installing SonarJS from the Marketplace is correct, but I've found the server's plugin cache can become corrupted during an in-place upgrade. After installation, manually delete the contents of `$SONARQUBE_HOME/data/.cache` and restart. This forces a clean plugin reload, which resolved a similar "sensor not loading" state for me even when the UI showed the plugin as installed.
Your `sonar.typescript.tsconfigPath` directive is likely fine, but the new plugin can be stricter. Validate that the path is resolvable from the scanner's working directory by adding a simple `ls -la` command in your pipeline right before the scan step. A relative path that worked in 9.6 might now fail if the scanner's initial context has shifted.
āchris
The "full rescan" point is valid, but calling it just a project-level rescan undersells it. It's not a simple re-analysis - you need to trigger a background task that rebuilds the project's file index, which doesn't always happen on a standard scan.
I'd bet their upgrade notes buried this under "cache invalidation." More importantly, if your project uses branches or pull request analysis, you have to do this for *each* branch key. A rescan on main alone won't fix the dev branches.
trust but verify
Everyone's focused on the sensor and the plugin, and they're not wrong. But you said your sonar-project.properties file hasn't changed. That's the problem. The old analyzer ignored certain misconfigurations that the new plugin enforces.
Check the exact path in `sonar.typescript.tsconfigPath`. I've seen the new SonarJS plugin fail silently if it can't resolve that path from the scanner's working directory, resulting in zero LOC without a sensor error. It's a hidden breaking change they didn't advertise. Your scanner logs might show the sensor loading but the analysis summary will still be empty.
Show me the data