Typescript analysis breaks based on analysis order

SonarQube Cloud
1
  • ALM used (Azure DevOps)
  • CI system used (Azure DevOps)
  • Languages of the repository (C#, javascript, typescript, html, css)
  • Error observed ##[error]ERROR: You are using version of TypeScript 2.6.1 which is not supported; supported versions >=3.2.1
    ##[error]ERROR: Failure during analysis, Node.js command to start eslint-bridge was: {NODE_PATH=D:\a\1\s\f\project1folder\node_modules} node d:\a\1\.sonarqube\out\.sonar\.sonartmp\eslint-bridge-bundle\package\bin\server 50139
  • Steps to reproduce
    • create a git with two projects using typescript
    • Configure project 1 to use an outdated typescript npm package
    • Run an analysis normally using sonarcloud
  • potential workaround (use global node_modules)

The above issue comes from sonarcloud randomly analysing one of the projects first and using the node_modules from that first project. If this project contains an outdated typescript version it will break all following typescript tests. Everything will be okay if the project with an up to date typescript package is analysed first. Is there a way to lock which package is analysed first? Otherwise how do you use the global npm package. I have tried to temporarily install a compatible typescript version for each project using npm install typescript@">=3.2.1" as well but this doesn’t seem to overrule the version in the package.json.

5

Hi,

Do you configure your TypeScript projects as modules of SonarQube project? (sonar.modules property is required for that).

If not, then basically we consider your 2 projects as a single one. We try to find TS in it by walking through the directories and trying to find node_modules/typescript dir. The order of dirs traversal is not definitive.

You have an interesting case which we didn’t think about before. Not yet sure how better to handle it, created this ticket to do that https://github.com/SonarSource/SonarJS/issues/1941.

As a workaround you can try to set NODE_PATH to the dir containing newer version of TS.

1 Like
6

Hi,

I do not configure them as modules since I wasn’t aware this was neccesary, however as I think you understand setting them as modules would not solve the problem entirely for the projects with an outdated version of typescript as a dependency. I have tried installing a correct version to all projects but due to issues with npm behaviour that hasn’t worked for me.

Setting the node_path to the project with an up-to-date dependency might work, however I am not entirely certain to which directory I’d need to set the node_path. Would this be the node_modules folder?

Also I only install typescript within the projects temporarily since that is the only neccesary local dependency for the scan. If setting the node_path, would I need to install other dependencies as well?

7

We need only node_modules/typescript, other dependencies are not required.
You might also install typescript in the root of SonarQube project, so that it’s above both of your projects.

8

I have tried setting NODE_PATH to the project root directory as well as the node_modules directory and typescript directory that are created below the root when I install typescript at the root of the project. In all of these situations I just get the ##[error]ERROR: Cannot find module 'typescript' error. Am I setting NODE_PATH to the wrong folder? I have confirmed that typescript is actually being installed.
Require stack:
- d:\a\1\.sonarqube\out\.sonar\.sonartmp\eslint-bridge-bundle\package\lib\tsconfig.js
- d:\a\1\.sonarqube\out\.sonar\.sonartmp\eslint-bridge-bundle\package\lib\server.js
- d:\a\1\.sonarqube\out\.sonar\.sonartmp\eslint-bridge-bundle\package\bin\server
Is the output right after the error after which setting node path is suggested.

Also, as a sidenote, is it possible to disable sonarcloud showing warnings during msbuild tasks without disabling the rules for these warnings entirely? The amount of warnings this generates for most projects makes it very hard to read through anyway so it isn’t really useful.

edit: I realised the NODE_PATH environment variable doesn’t persist outside my powershell script

9

I solved my issue using the following powershell script:

Write-Host "##vso[task.setvariable variable=NODE_PATH]$(System.DefaultWorkingDirectory)\node_modules\"
npm install typescript@">=3.2.1 <3.8.0"
npm list
2 Likes