For situations where an explicit Node.js install is required (non-standard architectures, old SQ versions), are there any known issues with using a newer major version of Node.js? They use semantic versioning (semver) so if SQ calls for Node.js version X.Y+ then it SHOULD be safe to use X.Z where Z>Y. But there are no guarantees for major release X+1 etc.
Has anyone encountered any issues where they used a newer major release than the one specified, and the SQ scanner didn’t like it (complained), or failed outright, or (even worse) failed in some subtle way?
The short answer is: for most setups on current SonarQube Server versions, your Node.js version doesn’t matter anymore.
Since SonarQube 10.4, the scanner bundles its own Node.js runtime and deploys it automatically for Linux x64, Windows x64, and Apple ARM64. The system Node.js on your CI host is bypassed entirely unless you’re on an unsupported architecture or have explicitly set sonar.nodejs.executable. See Node.js is no longer a requirement for analysis for the announcement.
If you are in the minority case where system Node.js is still in play (via sonar.nodejs.executable or an unsupported architecture), the historically documented failure mode for unsupported versions was a warning log rather than a hard failure, which is exactly the subtle breakage you’d want to avoid. The fix in that case is to explicitly pin a compatible version via sonar.nodejs.executable or upgrade to a version on the supported list.
Which SonarQube version and architecture are you running? Are you using sonar.nodejs.executable parameter?