TypeScript tsconfig.json detection fundamentally broken

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:

  1. parseConfigHost requires a member readFile with value ts.sys.readFile, extends will not work otherwise
  2. After calling parseJsonConfigFileContent, the result’s errors 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.