Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.

Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.

Reading getFileReferences_deduplicate, how is that test not just plain wrong? Both referenced projects are composite but include files that aren't listed in tsconfig... Is the test just misconstructed?

@typescript-bot pack this

Starting jobs; this comment will be updated as builds start and complete.

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/163392/artifacts?artifactName=tgz&fileId=4BBD992F9C62F18BF514A8E32B0D46424171CAF205EDBBEFDB3751CFB95F81DF02&fileName=/typescript-5.7.0-insiders.20240820.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.7.0-pr-59688-4".;

Should we add new event that gives list of all the config files looked up?

That really depends on what we would want to do with that.

The thing I could imagine is that an editor, when encountering a TypeScript file, could indicate that the file belongs to no projects and that there might be a configuration error.

For a JavaScript file, I think that's way more questionable.

Reading getFileReferences_deduplicate, how is that test not just plain wrong? Both referenced projects are composite but include files that aren't listed in tsconfig... Is the test just misconstructed?

Its so interesting how most of fourslash-server tests work. They open files that are tsconfig.json or sometimes package.json and depending on what projects are open we are either testing things correctly or we are not. I havent looked in detail why this happens but i think it has to do with first file or last file listed or something like that when there are no markers?

Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @mjbvz, @zkat, and @joj for you. Feel free to loop in other consumers/maintainers if necessary.

I'm trying to find in the baselines a good example of where we would (in the old method) would have been loading too much, but we aren't after this new method; is there a good example of this?

There are quite a few tests in tsserver/projectReferences and some in tsserver/inferredProjects and tsserver/configuredProjects

But here are few:

• tests/baselines/reference/tsserver/projectReferences/project-is-indirectly-referenced-by-solution.js:
  https://github.com/microsoft/TypeScript/pull/59688/files#diff-9e96549906aa6356aae0ece1b13f172138247c6f05e1f631a2b34fada60dbfcfL241
  tsconfig.json project is created with pending initial load (earlier we would have called updategraph on it)

• tests/baselines/reference/tsserver/projectReferences/when-file-is-not-part-of-first-config-tree-found-finds-default-project.js
  This one is test case from ancestor search so - you would need to look into commit 5980411 to see the diff with the real change of not loading "tsconfig" and updating the project 5980411#diff-3046210cf5d1de176213a77c818178c04f6623feb5cd5cba0e1d3756214f8322L102

Thanks, tests/baselines/reference/tsserver/projectReferences/when-file-is-not-part-of-first-config-tree-found-finds-default-project.js was the test case I was looking for. Everything else just looks to be slight shifts around but the same "amount" of loading.