Sorry for the late response
I don’t think so, the thread you refer too is more related to more fetching all tsConfigs in the repo, which is going fine, just the extending part is going wrong.
Let’s say we have 2 apps in our monorepo, each their own tsconfig refering to a shared tsconfig preset in a different package
// apps/my-app/package.json
{
"name": "@my-repo/my-app",
...
}
// apps/my-app/tsconfig.json
{
"extends": "@my-repo/tsconfigs/nextjs.json",
...
}
// apps/my-other-app/package.json
{
"name": "@my-repo/my-other-app",
...
}
// apps/my-other-app/tsconfig.json
{
"extends": "@my-repo/tsconfigs/nextjs.json",
...
}
// packages/tsconfigs/package.json
{
"name": "@my-repo/tsconfigs",
...
}
// packages/tsconfigs/nextjs.json
{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "Next.js",
"compilerOptions": {
"target": "es2021",
"lib": [
"dom",
"dom.iterable",
"ESNext"
],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"noEmit": true,
"incremental": true,
"esModuleInterop": true,
"module": "ESNext",
"moduleResolution": "Bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"plugins": [
{
"name": "next"
}
],
"types": [
"node",
"jest",
"@testing-library/jest-dom"
]
}
}
Resulting in the following;
10:36:03.163 INFO Creating TypeScript program
10:36:03.164 INFO TypeScript configuration file /my-repo/apps/my-app/tsconfig.json
10:36:03.166 WARN Could not find tsconfig.json: /node_modules/@my-repo/tsconfigs/nextjs.json/tsconfig.json; falling back to an empty configuration.
10:36:03.558 WARN At least one tsconfig.json was not found in the project. Please run 'npm install' for a more complete analysis. Check analysis logs for more details.
10:36:03.559 INFO Starting analysis with current program
10:36:03.648 INFO Analyzed 223 file(s) with current program
It knows it has to extend and tries to fetch the extend path. However, if the extends already refers to a json file, it still appends tsconfig.json behind the path, resulting in not being found. I think this is a bug in SonarJS
Still an issue in the latest SonarScanner CLI; 7.1.0.4889
