Node.js is no longer a requirement for analysis

Clean Code Sonar Updates
, , , ,
1

Hello Sonar community!

Starting today, most users no longer need to install Node.js in their environment to be able to analyze JavaScript, TypeScript, and CSS code.

Node.js is now automatically downloaded from SonarCloud or SonarQube during analysis on Linux x64, Windows x64, and Apple ARM64 systems.

This is deployed in SonarCloud and will be part of SonarQube 10.4.

Other architectures (not listed above):

  • You will still need to have a compatible Node.js version or the analysis will fail.
  • We suggest using the latest LTS (currently v20). Versions below 16 are not supported, and 16 itself is deprecated and will be dropped soon.
  • We might support more architectures in the future. Tell us your needs!

See the documentation for more details.

Please share your feedback if you encounter any issues.

Correction: For Apple we support ARM64 and not Intel. Sorry for the confusion.

11 Likes
2

Some more details:

Why this change?

Before this change, all users needed to install Node.js to analyze JavaScript, TypeScript, and CSS code, which caused several issues:

  1. It complicated CI/CD setup, especially for those using JS/TS/CSS as a second language.

  2. Users had to keep pace with Sonar’s Node.js deprecation policy.

  3. Some users couldn’t upgrade Node.js despite warnings, eventually leading to analysis failure, without any easy solution.

  4. Missing or unsupported Node.js versions provoked silent analysis failures, often going unnoticed for extended periods.

What’s the advantage?

Users on supported systems won’t need to worry about having a Node.js version compatible with Sonar analysis:

  1. Setting up a new analysis environment doesn’t require installing Node.js (unless you need it for your own purposes).

  2. There will be no conflicts with Sonar’s analysis if your project’s CI/CD requires an old Node.js version. No more deprecation warnings.

  3. You’re no longer responsible for keeping up with Sonar’s Node.js version upgrades!

  4. If you only had Node.js for Sonar’s use, feel free to remove it!

6 Likes
3

Hi,

we will update to Sonarqube Enterprise 10.4.1 next week.
Didn’t find a hint in the documentation from where Node.js is downloaded.

Is this configurable ? We use Sonatype Nexus Artifact Manager and i.e in Jenkins many tools
like nodejs / Maven … are installed from Nexus proxy repos.
Or do i have a setting / property to set the path to an existing Node.js installation ?

Gilbert

4

Hi Gilbert,

Since SonarQube 10.4, the Node.js runtime is bundled with SonarQube itself. The scanner downloads it to the CI/CD environment from the SonarQube instance for compatible platforms.

If you want to provide your own, you can use sonar.nodejs.executable. Keep in mind that it would need to be compatible. We recommend the latest Node.js LTS version.

Here’s the link to the relevant docs.

5

Hi,

this means that in a Jenkin pipeline the wrapping of the Sonar analysis within a nodejs scope ain’t
needed anymore ?

nodejs(configId: genericNpmSettings(), nodeJSInstallationName: 'nodejs-16') {
  withSonarQubeEnv(sonarenv) {
    withMaven(jdk: 'java-17-openjdk', maven: "${p.mvnVersion}", globalMavenSettingsConfig: genericMvnSettings()) {
      genericSh("mvn ${sonarDebug ? '-X' : ''} ${isDMZDE ? mvnDMZDEparams : ''} sonar:sonar 
      ${sqProjectVersion ? "-Dsonar.projectVersion=$sqProjectVersion" : ''} -Dsonar.branch.name=$BRANCH_NAME")
     }
   }
 }

I guess providing my own version via sonar.nodejs.executable has no impact for the download,
means the whole sonar-javascript-plugin-10.11.1.25225-multi.jar with a size of > 80mb will be downloaded.

Gilbert

6

Node.js requirement changes in the latest version are another breaking change in 10.x for us.

The new 10.x scanner rule states the following:

1. The Node.js defined through the parameter sonar.nodejs.executable (absolute path to Node.js) if the runtime version is compatible.
2. The Node.js downloaded by the scanner from the SonarQube server during analysis if the detected architecture is one of the supported ones: Linux x64, Windows x64, and Apple ARM64.
3. The Node.js defined with node in the PATH if the runtime version is compatible.

Using the parameter -Dsonar.nodejs.executable is not really an option for us because we have many CI/CD server/agents across our Enterprise and I certainly cannot ask the teams to hardcode a path for thousands of jobs with this parameter.

Option #3 should really be Option #1 instead, which is the current behavior of the scanner. I don’t understand why this was changed. The scanner should still default to use the node that is already on the path of the current machine executing the scan which is what we have today. This allows us to control the version and configurations of Node for our Enterprise without having tools install on the fly which is a security issue.

Using the -Dsonar.nodejs.executable is not a solution since it can be different across CI/CD agents. You are forcing the developers to hard code paths in their pipelines, which they may or may not even be aware of. The whole purpose of using the path is so we can control this at the server level without teams needing to set these variables.

It should be in this order:

1. The Node.js defined with node in the PATH if the runtime version is compatible.
2. The Node.js defined through the parameter sonar.nodejs.executable (absolute path to Node.js) if the runtime version is compatible.
3. The Node.js downloaded by the scanner from the SonarQube server during analysis if the detected architecture is one of the supported ones: Linux x64, Windows x64, and Apple ARM64.

Can we get this fixed in the next 10.x release before this goes LTS??

7

Hi Lance,

Setting the parameter should not be necessary, the analysis should pick up the Node.js binary in your path if you’re running an unsupported platform.

Could you share a bit about your setup so I can help?

  • What version of SonarQube are you using?
  • What architecture(s) and environment(s) are you using for CI/CD?
  • What version of Node.js do you have in your CI/CD?
  • Are you getting any analysis warnings or error messages?
8

Re-reading your message:

This allows us to control the version and configurations of Node for our Enterprise without having tools install on the fly which is a security issue.

Can you confirm that this means that the embedded Node.js runtime is working well for the analysis, but you want to override it?

Unless I’m missing something, you shouldn’t need to hardcode the location if you control the environment, for example: -Dsonar.nodejs.executable=$(which node) will use the version in the PATH.

For context, we don’t take the value of the PATH first since 1/ This would no longer allow users to override it with a parameter, and 2/ For most users, the embedded version is preferable since it is guaranteed to be compatible with the analysis.

9

There are multiple OS platforms so the -Dsonar.nodejs.executable=$(which node) wont work universally. Also this would force changes to existing scripts. It seems like you were only looking at individual users on desktops when considering this change.

My main point is that you have essentially taken away the option to default to using the Node already pre-installed in the PATH. You have changed the default behavior to Option #3 which essentially will never get used.

What I am asking is that you restore the ability to tell sonar to use the Node that is already in the PATH.

It looks like you provided this ability for Java with this:

sonar.scanner.skipJreProvisioning=true

Perhaps you could also add this for Node:

sonar.scanner.skipNodeProvisioning=true

1 Like
12

Thanks for the clarification and details.

Assuming you already have separate scripts for Unix-like and Windows:
For Windows you should be able to use where node in a batch file or Get-Command in PowerShell. Those should respect any settings in %PATHEXT% too.

Also, I’ve been informed that you have an ongoing support ticket.

I suggest we continue the conversation through that channel to not duplicate information.

13

Update:

For visibility, we have now added support for sonar.scanner.skipNodeProvisioning. Thank you @lweitzel!

This is included in SonarQube 10.7.

We also plan to add an environment variable as another means to set this value, which will be available in the next version of SonarQube.

1 Like
14

I am applying 10.7 this week so will give it a try. When you say next version, do you mean 10.8?

1 Like
15

Hi Lance, yes, I mean SonarQube 10.8