SonarQube excluding TypeScript Declaration Files (.d.ts) automatically?

Does SonarQube exclude TypeScript declaration files (.d.ts) automatically?

I am analyzing a TypeScript project which contains many .d.ts files but they don’t show up in SonarQube. From the configuration point of view (source inclusions and exclusion etc.), I’d say they should show up (regular .ts and .spec.ts show up). SonarQube also analzyes the corresponding tsconfig.json file and then reports

INFO: Analyzed 33 file(s) with current program

which is exactly the number of all .ts files minus the .d.ts files.

The issue with this is that I want to import ESLint issues but the issue on .d.ts files are skipped with warnings like this:

WARN: No input file found for /path/to/project/src/some/path/file.d.ts. No ESLint issues will be imported on this file.

SonarQube version
Scanner version

hello @julrich_bee360,

sorry for the late reply. Indeed we do exclude .d.ts files intentionally because we thought that they are usually not written by hand, but generated, so it doesn’t make sense to raise issues on them.

What is the origin of your .d.ts files? Do you find eslint issues valuable?

we thought that they are usually not written by hand, but generated

No, .d.ts files can very well be written by hand, although the TypeScript compiler can also generate them for .ts files. The use cases for writing declaration files by hand are adding type support for untyped APIs that should be used from within TypeScript. This is typically the case for pure JavaScript APIs.

For example, the complete “Definitely Typed” project (see typescript - What is "DefinitelyTyped"? - Stack Overflow for a high-level description of the project) consists of hand-written .d.ts files for pure JavaScript npm packages.

What is the origin of your .d.ts files?

They are written by hand. They provide type information for a Java API which can be accessed via JavaScript (Nashorn or GraalJS).

Do you find eslint issues valuable?

Sure! Having all code quality related issues in one place makes total sense IMO.
And ESLint also provides an easy way to create custom rules by detecting undesired constructs via the AST (no-restricted-syntax - ESLint - Pluggable JavaScript Linter).

1 Like

I created a new topic for a proposal to remove this restriction: Allow analysis of TypeScript declaration files (.d.ts)

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.