[WIP] Open bigger set of configured projects when opening composite project for operations that operate over multiple projects like rename

[sheetalkamat]

• Add tests
• Bigger project opening set means that much longer time to do the operation. So we need some optimizers for this. There are multiple options here and one or many can be chosen.
  • Need some sort of indicator if the operation is exposing something that's outside scope of the project. (eg renaming local function in checker shouldn't need to open this so that we are delaying this as much as possible)
  • May be send more locations as event (eg in find all references if not rename can handle that)
• We need to have way to unload projects (with some sort of priority based) when the operation might cause too many projects resulting in it running out of memory. This could probably be different PR but then we need some sort of flag to opt out of opening that bigger set so that people have a way to work with the set.
• need to have sourceMap decoders per declaration file and cache them based on sourcefile or map file changes to avoid corruption and impact on memory. This can be separate PR but that needs to go first. There is wip branch for this.

[bajtos]

Re-posting my comment #30823 (comment):

Personally, I will happily trade off performance for "Find all references" and "Rename symbol" that actually works.

In https://github.com/strongloop/loopback-next, we have configured TypeScript to treat the entire monorepo as a single project, so that we can use "Find all references" and "Rename symbol".
We also don't use declaration maps, therefore cross-project imports are resolved against the original TypeScript sources, not via .d.ts and .d.ts.map files.

This setup works pretty well for us and I am not aware of any performance or memory limitation when working in VS Code. If the performance of #28261 is similar, then I would happily accept it.

Why we want to migrate from our single-project setup to project references when VS Code experience is good now? The problem is that our build times are super slow. We are building each monorepo package independently, because each package has its own outDir, e.g. packages/{name}/dist. Because cross-project imports are resolved against the original TypeScript sources, I suspect that the compiler is repeatedly parsing each TypeScript source file again and again for each top-level package depending on it.

Anyhow. Is there a way how to finish #28261 sooner, possibly without performance optimizations and perhaps behind a new feature flag?

[sheetalkamat]

@bajtos Thank you for your feedback. I am currently investigating #32028 and looking to improve project references editing experience and you might be interested to give that a try as well.

[bajtos]

Thanks, #32028 looks very promising! I'll give it a try and let you know about my experience.

[sheetalkamat]

Closing in favor of #33287