Allow analysis of TypeScript declaration files (.d.ts)

SonarQube Server / Community Build Product Manager for a Day
,
1

As discussed in the topic SonarQube excluding TypeScript Declaration Files (.d.ts) automatically?, SonarQube currently automatically excludes TypeScript declaration (.d.ts) files.

Since those files are written manually in some cases (see the other topic for examples), it makes sense to analyze them with SonarQube as well.

So I propose to remove the implicit exclusion of .d.ts files and enable analyzing declaration files.
I guess in projects where there are automatically generated .d.ts files in the source directories, those files can be excluded using sonar.exclusions explicitly instead.

1 Like
5

Hi Jochen,

We initially decided to ignore them by default since most cases we were seeing had generated .d.ts.
But, I agree this is not ideal.

If I’m not wrong, you mentioned no-restricted-syntax in the other thread, as one possible rule to use in these files. Is this the main reason you would want to analyze the .d.ts files? Or do you have other reasons to want them in the analysis? Perhaps useful rules we could add?

I’ve been tracking this and I’d be happy to have a chat about it :slight_smile:
Let me know,

Cheers,
Gabriel

7

If I’m not wrong, you mentioned no-restricted-syntax in the other thread, as one possible rule to use in these files. Is this the main reason you would want to analyze the .d.ts files? Or do you have other reasons to want them in the analysis? Perhaps useful rules we could add?

Well, we run all our ESLint rules on these files as well but also have some rules which are run only on the .d.ts files like the no-restricted-syntax and also no-restricted-imports. Both with very specific configurations for reasons in our special setup. So nothing I would see as a general rule.

Generally, I guess any rule that concerns types is also a good candidate for .d.ts files.

But because you were asking about the no-restricted-syntax rule: this is actually something that I am missing in SonarQube in general: a way to implement simple custom rules. ESLint’s no-restricted-syntax rule is a perfect solution for this: you specify a CSS-like selector string to identify elements in the AST which are then reported. This is very flexibel. However, it requires a way to see the AST (something like https://astexplorer.net) else it’s hard to get the selector strings correct.

1 Like