Currently, for determining which tsconfig.json
to use when analyzing a .ts
file, SonarJS uses the following logic:
Not only does this code have bugs, it is also unsuitable for certain valid TypeScript projects.
The bugs are as follows:
-
parseConfigHost
requires a memberreadFile
with valuets.sys.readFile
,extends
will not work otherwise - After calling
parseJsonConfigFileContent
, the result’serrors
member needs to be checked for errors (this would’ve lead to the discovery of bug 1)
Now, the rest of SonarJS hinges on parsed.fileNames
actually containing all files. However, this is not the case at least for modern Angular! It uses the “solution-style tsconfig”.
This results in the following tsconfig.json
:
{
"files": [],
"references": [
{
"path": "./tsconfig.app.json"
},
{
"path": "./tsconfig.spec.json"
},
{
"path": "./e2e/tsconfig.json"
}
]
}
The files
array is intentionally empty. This will never return anything in fileNames
after being parsed.
Of course, there’s also tsconfig.app.json
, which we could specify manually. However, this file contains the following:
{
"extends": "./tsconfig.base.json",
"compilerOptions": {
"outDir": "./out-tsc/app",
"types": []
},
"files": [
"src/main.ts",
"src/polyfills.ts"
],
"include": [
"src/**/*.d.ts"
]
}
This means it will result in exactly two files in fileNames
: main.ts
and polyfills.ts
. Also not suitable for SonarJS.
What SonarJS needs is an option to just use that tsconfig.json
. Alternatively, it could also just use the closest tsconfig.json
by default, which may not be entirely accurate but is still better than refusing to analyze anything at all.
Additionally, SonarJS should support TypeScript Project References.