Drop of Node.js 12 support and deprecation of Node.js 14 support

Sonar Updates
1

Hello SonarQube, SonarCloud, and SonarLint users!

The analysis of JavaScript, TypeScript, and CSS requires that Node.js be available in the environment where analysis is performed. To continue providing you with the best code analyzers possible, we periodically update the runtime version that is required in the scanner environment.

The currently supported Node.js LTS version is 16. We urge all users not already on Node.js 16 to upgrade as soon as is practical.

For those still on Node.js 12, you should be aware that the OpenJS Foundation has considered Node.js12 EOL since April 2022 and has been deprecated in Sonar products since that time (with warnings in the analysis logs and user interfaces). We announced this back in March: Drop of Node.js 10 support and deprecation of Node.js 12 support

Today, we are letting you know that on September 15th the use of Node.js 12 will no longer be supported by SonarCloud. We have proactively reached out to the organizations still running analyses with this older runtime. Support will also be removed in SonarQube v9.7, as well as versions of SonarLint released after September 15th 2022.

We are also letting you know that the use of Node.js 14 (which will be considered EOL by the OpenJS Foundation in April 2023) is now deprecated in Sonar products, and that support for Node.js 14 will end no earlier (and likely no later) than April 2023.

Please note that this change does not have any impact outside of your analysis runtime.

No changes are required to the code you are writing or any runtime dependencies. It only means that the minimum runtime version available in your environment has changed.

Below you can find information related to each of our three products.

SonarQube and SonarCloud

The Scanner Environment documentation for SonarQube and SonarCloud has the most relevant information regarding Node.js version support. For SonarQube, this documentation will be updated when SonarQube v9.7 is released.

Outside of these recommendations, if the default node in the PATH on the machine where analysis is executed is not already Node.JS 16, you can either:

  • Install a newer version of Node.js as the default node in your scanner environment
  • Point to another Node.js executable using the sonar.nodejs.executable analysis parameter

SonarLint

SonarLint for Visual Studio

SonarLint for Visual Studio will first attempt to use the version of Node.js that launches with your flavor of Visual Studio.

If no compatible version is found, SonarLint will check for Node.js installations in your PATH until a compatible version is found.

Finally, a Node.js executable can be pointed to using the SONAR_NODEJS_PATH environment variable

SonarLint for VSCode

If you are using a version of Node.js that is too old, a popup will appear in VSCode

928Ă—280 24.9 KB

You can either update the default node in your PATH, or point to a specific Node.js executable in your VSCode Configuration (sonarlint.pathToNodeExecutable)

SonarLint for Eclipse, IntelliJ

  • SonarLint for Eclipse and SonarLint for IntelliJ will look for the first node executable in your PATH, otherwise, you can specify the Node.js installation in your IDE settings.

Do you have any questions? Don’t hesitate to let us know.

4 Likes
2

Hi Colin,

We got this error on SonarCloud “JavaScript/TypeScript/CSS rules were not executed. Only Node.js v14.17 or later is supported, got 14.16”. We don’t have any plan to upgrade in near future.

We also check the Node.js version support on the documentation for Sonarcloud & found there’s no specific mention of version 14.17.

So, hopefully, you can support all node version 14, this is currently a blocker for us.

3

NodeJS 14.16 has several open CVEs that are fixed in newer versions.

In 14.19.0 there is only one left and in the latest 14.20 there is no known CVEs, at least according to these reports.

If your business has a reason to stick to a version with of NodeJs that has known High CVEs that allows for remote code execution, that’s your call but I support Sonar’s decision to drop support for such versions that are very insecure. There should be no compatibility issue caused by upgrading from NodeJS 14.16 to 14.20.1.

If I were you I would inform the InfoSec team of the CVEs and work with whomever is preventing an upgrade to asses the business risks, including legal ones.

For example if your company is doing business in Indonesia:

3 Likes
4

Hi Stephane,
Don’t get me wrong, I totally agree with you, we should take care of all of the security issues, in an ideal world yes, but in the real world, there’s always a trade-off.

Anyway, what I want to highlight is there should be an announcement from SonarCloud as a service provider to their customer if they want to drop a specific version (even for a minor version change). For node 14, it’s deprecated so I assume we still have time to upgrade to the newer version (16, 18).

This is not good for our business as well, now our code run without a code quality check.
We hope Sonarloud can re-consider this.

5

SonarCloud is showing me “The last analysis has a warning” with the detail “Using Node.js version 14 to execute analysis is deprecated and will stop being supported no earlier than May 1st, 2023. Please upgrade to a newer LTS version of Node.js [16, 18]”

I thought we did configure it to run in Node.js 16:

  - uses: actions/setup-node@v2
    with:
      node-version: "16"
      registry-url: "https://registry.npmjs.org"
  ...
  - name: SonarCloud Scan
    uses: sonarsource/sonarcloud-github-action@v1.6
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

but that sonarcloud-github-action runs a docker container, which is presumably where the Node.js v14 comes in … so isn’t it Sonar itself that needs to update its Node.js version? :slight_smile:

Probably that Docker image comes from GitHub - SonarSource/sonar-scanner-cli-docker: Docker image for SonarScanner CLI and the Dockerfile at tip of master there sonar-scanner-cli-docker/Dockerfile at e03fc57000448b5809346576ea39b38fcc9f601b · SonarSource/sonar-scanner-cli-docker · GitHub still specifies only nodejs>12.

6

Tried making a PR changing the GH action version:

  - name: SonarCloud Scan
    uses: sonarsource/sonarcloud-github-action@156db6fef3e168e4972abb76de0b32bbce8ec77a
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

and didn’t get the warning in the Sonar analysis of that branch. So maybe you just need to issue a new release of sonarcloud-github-action, as the GH actions marketplace page SonarCloud Scan · Actions · GitHub Marketplace · GitHub stil directs people to “Use latest version” meaning v1.6.

7

Yep, probably the salient change was SQSCANNER-103 DOCKER-52 Updating Alpine to 3.15. Fixes zlib bug. by lukasz-jarocki-sonarsource · Pull Request #148 · SonarSource/sonar-scanner-cli-docker · GitHub which updated Alpine to 3.15, which has nodejs 16.13 (Alpine 3.14 has nodejs 14.17.0), first released in the 4.7 versions of the docker image, which were pulled into sonarcloud-github-action last month: Update sonar-scanner-cli to v4.7 (#34) · SonarSource/sonarcloud-github-action@64d3b08 · GitHub and it hasn’t been released since.

8

Hello Azhari,

Sorry to hear this. You are right in that we are letting you down in not documenting the minor version required. We will update our documentation to be more explicit.

To be clear, we do support Node.js LTS v14 as deprecated, however that does not mean we support all its old minor releases. Some of them predate the LTS status. Node.js recommendation is that users of the LTS install the latest release and keep up with the updates. As far as I know, there is no reason not to install the minors and patches for an LTS version.

In this case, there have been 18 minor or patch releases since v14.16.0, including bugs and vulnerabilities, spanning a year and a half. The latest v14 release is v14.20.1, which came out last week and includes vulnerability fixes.

I hope this information helps you.

Gabriel

9

Hello @gthb,

Thanks for bringing this up. We are looking into this. I’ll get back to you with any update here.

Gabriel

11

Hello @gthb,

Following your question, we released a new version of the action:

Nevertheless, our recommendation is to always use SonarSource/sonarcloud-github-action@master, as it is documented in our tutorials and main docs. This will ensure you are up to date!

Best,
Gabriel

1 Like
14

As GitHub’s security guide indicates, using a floating tag like @master is not their first recommendation:

Note that there is risk to this approach even if you trust the author, because a tag can be moved or deleted if a bad actor gains access to the repository storing the action.

I wish there were a warning or other qualifying statement accompanying your recommendation to use @master

15

Hello Joe,

Welcome to the Community!

Please note that we are aware of this and working on a more suitable solution.
For now, you can use the newest version of the action (see above), if that is what you prefer.

Kind regards,
Gabriel

16

This is still an issue for me. It seems the base Docker image for the github actions is sonarsource/sonar-scanner-cli:4.8 which is problematic. Getting the node version for that image confirms the issue we are all experiencing:

> docker run -it --rm --entrypoint=node sonarsource/sonar-scanner-cli:4.8 -v
v12.22.9

The previous docker image version - 4.7 was a different story:

> docker run -it --rm --entrypoint=node sonarsource/sonar-scanner-cli:4.7 -v
v18.12.1

So avoiding the master tag as recommended was the solution for me:

            - name: SonarCloud Scan
              uses: SonarSource/sonarcloud-github-action@v1.7
              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                  SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
1 Like
17

Nevertheless, our recommendation is to always use SonarSource/sonarcloud-github-action@master , as it is documented in our tutorials and main docs. This will ensure you are up to date!

Unfortunately this advice didn’t age well. The recent breakage proves that 's better to follow GitHub recommendations and not use @master. Instead use dependabot for checking if there is a new, working (!) version of the action available.