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 
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.
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.
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.