Make cross-file go-to-definition work in the syntax-only server

[DanielRosenwasser]

One of the original motivators for the syntax-only server was to make sure that users could navigate around their project, and inter-file go-to-definition is table-stakes. Some of this is already described in #37713, but the idea is:

// @filename: foo.ts
export interface Stuff {
  foo: string;
}

export function foo(x: Stuff) {
}

// @filename: bar.ts
import { foo } from "./foo";
import * as fooModule from "./foo"

/**/foo()

fooModule./**/foo();

Go to definition on either call to foo should just work. Go to definition on the import path should also work. We can do this by performing a super-basic basic resolution of the path.

If there's an export *, we should consider trying to continue the search too.

[sheetalkamat]

Investigated this on how to go about it..
Instead of doing some magic on the fly, whenever someone asks for LS for semantic operations, create a project that either resolves relative imports only in open file (potentially whole tree with only relative import/export resolutions). (and we can do this when someone asks for completion/quick info instead of when opening the file)
I think this might be simplet than cooking up goto def/completions on the fly.

[DanielRosenwasser]

Does that also mean that we'll get slightly more accurate type information?

For example, if checker.ts is a module, and types.ts is a direct dependency, then in that case would every type reference be resolved?

(CC @minestarks since you had thoughts around different scenarios)

[sheetalkamat]

@DanielRosenwasser @RyanCavanaugh do we really want this.. we have not received any feedback on partial mode so its hard to tell if its worth the extra work that needs to be done and what all scenarios can be made to work and what is limitation...

[DanielRosenwasser]

Well that was the original motivating scenario for some teams, that eventually produced partial mode itself. @brieb and @unindented might be able to give a sense of whether cross-file go-to-definition on startup currently feels like a bottleneck, but given that we now are expected to run beyond just in the desktop, there might be more thought that needs to go into this.

[unindented]

cross-file go-to-definition on startup currently feels like a bottleneck

It does take a while for our type definitions to load on startup (~30s), so if you need to navigate immediately after starting the editor it gets a bit annoying.

I also see type definitions take a while to load after navigating across projects by Cmd + clicking references, and then going back with Ctrl + -. I can't repro consistently, so it must be something about some type definitions getting evicted from memory after a while.

---

Just for my understanding, partial mode is that behavior where Cmd + clicking a reference whose type definitions haven't loaded yet tries to take you to a useful place in the same file?

[sheetalkamat]

Ok will investigate this in 4.3 to see how we can improve this.

[brieb]

Great, thank you so much for investigating! (And happy new year!)

Yes, anything that improves the editing experience while booting up large projects is very welcome and helpful. In lieu of our project startup itself being fast, the introduction of this partial editing mode has helped engineers stay productive with the most common editing tasks while things initialize.

In the current experience for us, going to definition on an imported symbol first navigates to the import statement. Then going to definition again finds the local usages in that file (see screenshot below for demonstration). That behavior is less intuitive than navigating to the imported file (which is what happens once the server is fully initialized).

[sheetalkamat]

#42539 handles jumping to the files.. #38836 to track handling unresolved locals/members