Dont open composite projects to determine if script info is part of project

[sheetalkamat]

Projects now load by reading config file and getting root files. If the config marks project as composite, the project isnt loaded right away to determine if opened script info belongs to it. Instead if root file names has fileName of script info we are opening, or if its matched by file/include/exclude in case of extra files (like .vue which is handled by plugins) then open that project.

This also adds back change for #57196

Open questions now handled

1. Right now, if we can't find open project, just like before we send configDiag (which is errors from the project) for all the projects we loaded as part of lookup. But this is not complete list anymore because we might not create projects that are not needed. Should we add new event that gives list of all the config files looked up. d18d9bc handles this by adding needDefaultConfiguredProjectInfo to ProjectInfo request to get information about tsconfig files looked up that didnt match by roots and projects that were loaded but determined to not be default projects

2. There are two getFileReferences test which were baselining file references across two projects. I am not sure what the expected behavior is but fouslash-server tests for both these open tsconfig.json file which goes into inferred project and doesn't open the referenced projects. I have for now updated test to open files from the expected projects that are supposed to be open. But is it supposed to behave like find all references? where it tries to load project tree and get the references after that? Tests are getFileReferences_deduplicate.ts and getFileReferences_server2.ts Fixed in 4c7280c to handle it similar to find all references to open and load ancestor projects

[typescript-bot]

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.

[jakebailey]

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?

[DanielRosenwasser]

@typescript-bot pack this

[typescript-bot]

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

Command	Status	Results
pack this	✅ Started	✅ Results

[typescript-bot]

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/[email protected]".;

[DanielRosenwasser]

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.

[sheetalkamat]

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?

[typescript-bot]

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.

[jakebailey]

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?

[sheetalkamat]

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

[jakebailey]

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.

[jakebailey]

I have not tested it on our examples of over-loading, but the baseline diffs seem right. PR needs a rebase, though.

@DanielRosenwasser maybe you have a good test case for this?

[Knagis]

Small feedback from our monorepo (>300 TS projects).

Opening some random configuration script, for example, jest.config.cjs - which we really didn't think of at all when discussing tsconfigs.. The jest config is within a project that isn't even referencing most of the projects, just some 20 or so common projects.

5.5.4 - "Initialize JS/TS language features" takes ~60 seconds, tsserver process uses ~1.5GB memory
5.7.0 - "Initialize JS/TS language features" takes <1 sec, tsserver process uses ~180MB memory

We didn't even know just how much we needed this change, thank you!

[3Spiders]

very cool, it solved our stubborn problem.