.js.flow files not excluded by default sonar.javascript.exclusions despite being in node_modules

SonarQube Server / Community Build
1

Hello all,

SonarQube attempts to parse .js.flow (Flow type definition) files and throws parse errors instead of skipping them. This happens even when the files are inside node_modules, which should be covered by the default JS exclusions.

Expected behavior

.js.flow files should either:

  1. Be recognized as Flow type definition files and skipped — similar to how .d.ts TypeScript declaration files are excluded
    by default, OR
  2. Be covered by the existing sonar.javascript.exclusions=/node_modules/ default when located inside node_modules Default exclusions for JS/TS

Actual behavior

SonarQube picks up .js.flow files and attempts to parse them as JavaScript, resulting in parse errors:

18:13:45.296 INFO  Sensor AbapSquidSensor [abap]

18:13:45.296 INFO  Sensor AbapSquidSensor is restricted to changed files only
ERROR Unable to parse file: node_modules/global-agent/dist/types.js.flow
ERROR Parse error at line 67 column 3:
62: export type ProxyAgentConfigurationType = {|
63:   +environmentVariableNamespace: string,
64:   +forceGlobalAgent: boolean,
65:   +socketConnectionTimeout: number,
66: |};→  EOF

Workarounds

Currently the only ways to suppress this are:

  1. Add a global exclusion in the scanner configuration:
    sonar.exclusions=/node_modules/

  2. Or explicitly extend the JS exclusions:
    sonar.javascript.exclusions=/node_modules/**/*.js.flow

Question

Should .js.flow files be added to the default exclusions the same way .d.ts files are? These files are never executable —
they are pure type metadata, identical in purpose to TypeScript’s .d.ts declaration files.

Server version: SonarQube Enterprise Edition 2026.1

Sonar Scanner CLI : Latest version (8.0.1.6346)

2

Hi,

Could you add -Dsonar.verbose=true to your analysis command line and paste the resulting analysis log here, redacted as necessary?

Based on the log snippet you’ve provided, this is coming from ABAP analysis, not JS/TS analysis. I think maybe the reason the standard node_modules exclusion isn’t kicking in is because the JS analyzer is being invoked from the ABAP analyzer…? I’m hoping the log will tell us more.

 
Thx,
Ann

3

c

Hi Ann,

Thank you for the suggestion.

I enabled the verbose mode using -Dsonar.verbose=true as recommended. Below is a snippet from the analysis logs:

23:44:58.899 INFO  Sensor AbapSquidSensor [abap]
23:44:58.899 INFO  Sensor AbapSquidSensor is restricted to changed files only
23:44:58.945 INFO  21 source files to be analyzed
23:44:58.950 ERROR Unable to parse file: file:///home/runner/Project1/node_modules/global-agent/dist/types.js.flow

From the logs, it appears that the issue is triggered by the ABAP analyzer, not the JS/TS analyzer.

I also noticed that other files inside node_modules, such as .yml files, are being analyzed as well. It seems the YAML analyzer is also scanning files inside node_modules.

Based on this behavior, I expected the node_modules directory to be ignored by all analyzers, not only the JS analyzer.

Could you please confirm if this behavior is expected?

Thanks,

Eman

4

Also I notice the *.json file are ignored inside the node_modules while .yml file get scanned

00:12:01.623 INFO  Analyzer extracted to /home/runner/project1/.scannerwork/.sonartmp/analyzer/analyzer
00:12:01.624 INFO  Starting analysis.
00:12:01.625 DEBUG 'node_modules/@ungap/structured-clone/.github/workflows/node.js.yml' generated metadata with charset 'UTF-8'
5

Hi,

Could I have the entire log, redacted as necessary?

 
Thx,
Ann

6

Hello Ann,

Sure this is the log file

file.log (815.9 KB)

thanks,

Eman

8

Hi Eman,

Thanks for the log. I wanted to see if somehow the ABAP sensor was trying to hand off to the JS sensor, but I’m not seeing any evidence of that. Just a straight up attempt to parse node_modules files as ABAP. :woman_shrugging:

Could you share your analysis configuration, redacted as necessary?

 
Thx,
Ann

9

Hello Ann,

Thank you for response. I have provided the analysis configuration below. But I’m still confused why the node_modules get scanned by other languages as it should be ignored not just by JS/TS it should be ignored by all the languages.

SONAR_ARGS="
    -D sonar.projectKey=$PROJECT_KEY 
    -D sonar.projectName=$REPO_NAME
    -D sonar.sources=. 
    -D sonar.host.url=$SONARQUBE_HOST 
    -D sonar.token=$SONARQUBE_TOKEN
    "

if [ "${RUN_MODE}" == "PUSH" ]; then
    SONAR_ARGS="$SONAR_ARGS 
    -D sonar.branch.name=$BRANCH
    "
else 
    SONAR_ARGS="$SONAR_ARGS 
    -D sonar.pullrequest.branch=$SOURCE_BRANCH 
    -D sonar.pullrequest.key=$PR_KEY 
    -D sonar.pullrequest.base=$BASE_BRANCH 
    -D sonar.scm.revision=$PR_HEAD_SHA
    "
fi
sonar-scanner $SONAR_ARGS

Thanks,

Eman

10

Hi Eman,

Remind me how you’re setting your exclusions? I don’t see them in your properties list. Also, and entirely tangentially, I’m a bit surprised by the spaces in your list between -D and sonar. I suppose you’re not having any trouble getting the values picked up? Because I would have told you that wouldn’t work.

And yes, the tension between these files being excluded specifically and only for JS analysis and being picked up by the ABAP sensor is… not great. I’m planning to escalate this, but I want to make sure I have all the facts before I decide where/how to escalate it.

 
Thx,
Ann

11

Hi Ann,

Thanks for the follow up.

At the moment, we don’t have any exclusions configured for this specific project. When needed, we usually set exclusions from the SonarQube UI using the sonar.exclusions property, rather than passing them through the scanner command.

Regarding the command line formatting, we haven’t faced any issues so far the properties seem to be picked up correctly during analysis despite the spacing.

Please let me know if anything is needed from our side.

Thanks again

Eman,

12

Hi Eman,

Thanks for clarifying. I’m out of ideas. I’ve flagged this for the language experts.

 
Ann

13

Hey @Eman_Harri,

sorry, that it took a while to respond. Thanks for reporting this. :folded_hands:

The good thing is, that the issue is pretty clear :blush:, i.e., the ABAP sensor takes files with the following file extensions into account .abap, .ab4, .asprog and .flow, hence, it also takes .js.flow into account which it should not.

I created a ticket to avoid falsely taking .js.flow files into account.

Meanwhile, if you do not need the ABAP Sensor, you can turn it off. Here are your options to do so:

  • Remove .flow as file extension for the ABAP Sensor:
    • GUI: Project Settings > General Settings > Languages > ABAP > Remove .flow, or
    • Property: sonar.abap.file.suffixes = .abap,.ab4,.asprog
  • Deactivate all rules for ABAP (e.g., by creating a new Quality Profile for ABAP)

Is one of these options applicable for you? Does it solve the issue? :slightly_smiling_face:

Cheers
Felix

15

Hello Felix,

Thank you for your response and for creating the ticket we really appreciate it.

The suggested workaround should help on our side for now.

However, I still have another concern we noticed during our scans: some shell scripts inside node_modules are being analyzed and picked up by the Shell analyzer, which ideally shouldn’t happen. From our understanding, node_modules should generally be excluded from analysis across all analyzers.

So it seems this is not limited to the .js.flow case with the ABAP sensor we are observing similar behavior with other analyzers as well.

Could you please confirm whether this behavior is expected, or if it should also be addressed?

Thanks again for your support.

Best regards,
Eman

16

Hey @Eman_Harri,

yes, it is currently expected that .yml files in node_modules are scanned by the YAML analyzer. I spoke to the responsible colleagues and they consider adding an exclusion for such. Thanks for bringing it up. :folded_hands:

If you want to exclude node_modules for any analyzers now, I think the way to go is what you said here:

This seems to have not been set for the log you shared as I can see the following in the log:

2026-03-17T00:11:59.3118844Z 00:11:59.287 INFO Excluded sources: **/coverage.xml, **/.git/**, **/*.ico, **/*.icns, **/*.svg, **/*.webp, **/*.jpg, **/*.jpeg, **/*.png, **/*.pdf, **/*.tiff, **/*.gif, **/*.ttf

which does not contain **/node_modules/**.

Does this clarify? :blush:

Cheers
Felix

17

Hello Felix,

Yes, that clarifies it thank you for the explanation.

We’ve implemented the exclusion:
sonar.exclusions=**/node_modules/**

We were mainly curious to understand why node_modules was being scanned and contributing to LOC in some cases, but this makes sense now.

Thanks again to you and Ann for the support, really appreciate it.

Just a small question do you happen to have an estimated timeline for when the exclusion behavior might be handled natively?

Thanks,
Eman

2 Likes
18

Hey @Eman_Harri!

Thanks again to you and Ann for the support, really appreciate it.

Likewise! :100: :slightly_smiling_face:

[…] estimated timeline for when the exclusion behavior might be handled natively?

Regarding .js.flow, we are implementing it today and it will be available with the next release of the ABAP analyzer. Thus, available to SonarQube Server with the next respective release and approximately in a few days on SonarQube Cloud.

Regarding node_modules, I cannot give an estimation, but I will ping the responsible colleagues and make them aware of this thread.

Cheers
Felix

1 Like
22

Hello @Eman_Harri,

Thanks for raising the concern about node_modules! We have just merged a PR to exclude this directory from JSON and YAML analysis, and this will be available in the next release of sonar-iac.

Best,

Peter

1 Like
23

Hello Peter,

Thanks for the update we really appreciate the quick support on this!

Best Regards,
Eman