typescript:S4328 suddenly detecting internal modules

This issue is suddenly coming up on thousands of imports in our project, imports from aliased paths defined in the tsconfig.json for our internal modules. Has anything changed in how this rule detection works?

Either remove this import or add it as a dependency.
Dependencies should be explicit typescript:S4328

More info:

This started breaking on Friday 16th.

Analysis before this issue included logs saying it found tsconfig files, e.g.:
“Found 64 tsconfig.json”

Those logs are now missing in the analysis logs.

I don’t know what version is being used, but I’ve been looking for recent changes that could be responsible, one is: Do not look up for tsconfig files if they are present in request body by victor-diez-sonarsource · Pull Request #3957 · SonarSource/SonarJS · GitHub

Another potential PR related to this: Use Node to resolve tsconfig by saberduck · Pull Request #3872 · SonarSource/SonarJS · GitHub

Hello @stevendarby,

indeed there has been a big change in how tsconfig files are handled. Before, the analyzer was going through all the tsconfig files and analyzing the files belonging to each ts program.

Now, instead, it tries to analyze the file with the nearest tsconfig.json file which includes the file being analyzed. It is indeed very possible that this ‘heuristic’ is not properly selecting the right tsconfig for the file, as there may be many tsconfigs actually including the file and the chosen one may not be the one the developer expects.
I would advise you to use the sonar.typescript.tsconfigPaths to force the analyzer to use the tsconfig file[s] you want.

That rule depends on the ‘baseUrl’ value of the tsconfig.json, so once the proper tsconfig with the correct baseUrl is picked up, these issues should disappear.

Cheers,
Victor

Thanks for the reply Victor, I’ll see if I can set the paths. We have at least 64, so it’ll take a while :smiley:

Out of interest, is it a goal of yours to keep changes non-breaking and to notify when there are breaking changes? How do releases work for sonarcloud, are there anouncements/changelogs etc. to keep an eye on?

Hi @stevendarby,

about setting the paths, if you add all 64 found in the file system, your results will not change. The idea behind setting the paths is to ignore certain tsconfigs that may be used for special targets, test contents, etc… but hardly ever all of them are needed for the sonar analysis. Please check this answer I wrote to another user: SonarLint analysis slow and resource intensive for a single Typescript file - #4 by victor.diez

Although I understand that this was for you a breaking change, for some other cases it was a fix, because when many tsconfigs are present, the analyzer will have to ‘guess’ which one should be used for dependency resolution for each file, and the only way to know would be creating a TS Program for each tsconfig, which would have an impact on performance. So, in this new release, we changed that heuristic, which should make ‘most’ projects work better than the previous strategy. But making it suitable for all TS projects is a non-trivial problem, and that’s why we recommend using the TS-specific sonar properties to tweak the tsconfig resolution.

Cheers,
Victor

Thanks, I’ll try to look into those optimisations later, currently just trying to get it back to how it was before to fix the expected broken CIs

ok, keep me posted, please. I would recommend starting checking where the baseUrl option is set. You can write me via PM if you prefer.

Cheers,
Victor

@victor.diez, something seems seriously wrong. Although I’ve used that setting to specify 3 wildcard paths and it’s now finding the same 64 tsconfigs as it used to (before Friday), analysis is taking almost an hour when before it took around 5 minutes. I don’t really understand the changes you’re proposing we make or why they’re suddenly needed. Such changes might take a long time, something we’d need to plan in, but in the meantime we’ll be getting false positives and very slow analysis.

This is an angular workspace, where the root folder has a tsconfig.base.json and each app and lib has a tsconfig which extends this. This is the way it’s been for years without a problem.

Chiming in to agree,

We started noticing failing CI builds due to timeouts starting on Friday. Analysis that used to take 4 minutes is now failing “halfway through” at 45 minutes.

The message detecting tsconfigs had disappeared and manually setting the tsconfig values does not solve the slowness.

Our codebase is set up similarly to Steven’s and we’ve been forced to disable analysis while we wait for a fix.

Hi @aporter-varicent,

Seems the solution that worked for @stevendarby (via PM) was to set sonar.typescript.tsconfigPaths with the tsconfig.base.json in the project root. Can you check if that works for you?

Cheers,
Victor

Thanks. Pointing to the project root tsconfig seems to have worked.

1 Like

Hi @aporter-varicent,

what kind of project you are working on? react? angular? are you using nx? We are trying to narrow the problem.

Thanks,
Victor

It’s the code for our “back-end” lambda, NodeJS.