A solution project is a composite project with references to other projects, but no files of its own?

@amcasey That appears to be the case, but I would appreciate confirmation as well. Also, how common is that as a pattern?

A solution project is project with project referenes but no files on its own.. (Eg https://github.com/microsoft/TypeScript/blob/master/src/tsconfig.json)

Note that we already handle solutions for scenarios like our own repo.. Wherein the tsconfig for compiler is in its own folder and named tsconfig.json so found for the file open in src\compiler ... This tries to solve cases if say that tsconfig was named tsconfig.compiler.json or was in src\compiler or src itself instead. Good repro scenario to look at would be the issues this PR is fixing.. #27372 has a link to https://github.com/OliverJAsh/jest-ts-project-references which demos the issue.

@typescript-bot pack this

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 914f358. You can monitor the build here.

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/67599/artifacts?artifactName=tgz&fileId=ED6224134493FAA69B7797634F6182922F217A4923B3181D8B91B238C9CBB63002&fileName=/typescript-3.9.0-insiders.20200310.tgz"
    }
}

and then running npm install.

There is also a playground for this build.

How did you identify the code paths that needed to be updated (i.e. how do you know you didn't miss one)?

Well i looked at all the calls to getConfigFileNameForFile which is where after finding solution project, we are changing the behavior

How did you identify the code paths that needed to be updated (i.e. how do you know you didn't miss one)?

Well i looked at all the calls to getConfigFileNameForFile which is where after finding solution project, we are changing the behavior

It sounds like anyone who calls getConfigFileNameForFile in the future will need to think about this as well. Is there some way we could organize the code to guard against a new caller failing to do so? Perhaps it could become a private helper of findConfiguredProjectByProjectName, for example?

Confirmed that #36708 and #27372 no longer repro. The tests work better if I launch the version of VS Code running against this change. 😝

Can a solution tsconfig.json file contain solution-wide compilerOptions? Is the configuration below valid?

// tsconfig.json
{
  "files": [],
  "references": [
    { "path": "./packages/client/tsconfig.json" },
    { "path": "./packages/server/tsconfig.json" },
  ],
  "compilerOptions": {
    "noEmit": true,
    "allowJs": true,
    "checkJs": true,
    "strict": true,
    "target": "ES2019",
    "module": "ESNext",
    "moduleResolution": "Node",
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "react"
  }
}

@kripod I think you're asking whether your client and server projects will automatically pick up those compiler options - no, they won't. If you want to inherit the configuration, you need to use extends in the derived/child projects.