Description
Background
Back in #37713, I suggested that TSServer could produce several look-up locations in go-to-definition in the absence of a full project; part of the concern was that in an environment where the TypeScript server is on the same machine as the file system, it's way cheaper to perform that operation. We never went that route, though @sheetalkamat did try to create miniature projects in partial semantic mode in #39476, and backed that out in #40026.
Since then, partial semantic mode has been generalized to work in web settings where neither the client nor the server have all the files available at once, but the client may be in a better position to see whether a
6846
given file exists. The most we do to leverage this is in @andrewbranch's pull request at #42539 which tries to construct paths from relative imports, but doesn't really work if your import needs to resolve to a .ts/.tsx file.
Idea
Coming back to the idea in #37713, we could produce a result that signals to the editor that TypeScript doesn't have enough files open to produce an answer - but if the editor opens some set of files on its behalf, then it might be able to.
In other words, some sort of response type for go-to-definition that has
- A list of entities TypeScript would like to resolve, each containing
- the specific file paths that TypeScript needs to try to resolve to load those paths
When this information is given to the editor, the editor can try to open the set of files and send fileOpen requests to TSServer with the appropriate file content. Once that's done, TypeScript can re-request go-to-definition to produce further results.
Beyond the file transfer, adding a single file to a small program is likely not to have considerable overhead for most users.
Risks/Drawbacks
- If opening files actually means opening editor tabs. That might not be desirable, especially if these requests have a noticeable delay. If a user closes this tab (or the tab is "ambient" and navigating away ends up closing the tab), then a user might end up with a "thrashing" editor experience where TSServer keeps trying to reload content.
- If a re-request results in another "open more files" response, then this can result in a cascading effect that might be very slow.
This mechanism
Related work
Relative References in Partial Mode
In #39476, @sheetalkamat had partial semantic mode try to construct a program out of only relative references. This was backed out in #40026.
unverified Go-to-Definition Results
In #42539, @andrewbranch had go-to-definition jump to files that might not actually exist. Editors had the option of handling these requests and occasionally suggesting creating a file if they didn't exist.