Sonarqube Failed to load module 'node:os' from vitest.config.ts on Azure DevOps Windows image

SonarQube Cloud
1

I use Azure DevOps and a Windows image for my analysis pipeline. I just switched from Jest to vitest recently and now see the following entry in the log:

Sonarqube Failed to load module ‘node:os’ from vitest.config.ts Illegal char <:> at index 4: node:os

It’s about an import like this: import * as os from ‘node:os’

I guess SQ uses an own TS parser and cannot parse node:os correctly? Can this be? How can I fix this?

cheers

3

Hello @jreimone,

can you please share the full debug analysis logs?

Cheers

4

2026-01-13-debug-log.log (39.3 KB)

Hi @victor.diez , please excuse me for the late reply. I really appreciate your will to help here. You can find my debug log attached. Therein, you find 4 lines with the contents described in my initial post.

5

Hello @jreimone,

did you run npm ci or npm install before running the analysis? This is coming from TypeScript when resolving the dependencies of your project.

Cheers

6

Yes sure, I run npm ci before. This Error is from the Analysis with SonarQube.

7

Can you share the details on how to run the scanner, please? Also, is @types/node in your package.json devDependencies?

9

I was able to reproduce this when running an analysis. Pinging @TaintAnalysis as it seems to come from the security analyzer

2 Likes
12

Hi @jreimone, thanks for reporting this. We’ve conducted a quick investigation that triggered some interesting internal discussions.

First, here is the most important takeaway:

TL;DR: These failure logs have no observable effect on your analysis results; you can safely ignore them.

Here are some more details on what is happening and the steps we intend to take:

  • The engine doesn’t currently have a model for the node:os module. This is generally fine, as the JavaScript ecosystem is vast and we cannot model every single module; however, node:os is important enough that we plan to model it as our first step.
  • Usually, when a module is not found, the engine should handle it silently and continue the analysis gracefully by using a default value.
  • However, in this specific case (for technical reasons too complex to detail here) the engine wrongfully attempts to load the module and triggers an error log before falling back to that same default value.
  • Because the engine still returns the correct default value after the error, your analysis results remain the same despite the failure messages you see in the logs.
  • Our second step is to fix this behavior at its root to ensure a much cleaner, noise-free experience.
4 Likes
17

@Samuele_Buro thanks for this thorough explanation and for taking care :+1:

2 Likes