Open DanielRosenwasser opened 3 years ago
From today's editor sync:
fileOpen
requests without actually opening the file. We don't have to always open tabs to open files in the editor.Be mindful of "barrel files" - branching might get very expensive.
export * from "./a";
export * from "./b";
export * from "./c";
export * from "./d";
export * from "./e";
export * from "./f";
// ...
export * from "./z";
In theory, we could stop at them if things are too ambiguous. We could employ some heuristics based on the file path too of "most likely" place to look. But if we always end up at these hops, that is not ideal.
but the client may be in a better position to see whether a given file exists
How would this ever be the case? It feels like to do this correctly, either the server needs to fully know how to do module resolution, or TS needs to generate and send the full list of lookup locations for any reference it would like to be able to resolve, like you mention in #37713.
One idea was that if clients have a directory tree available to them, that effectively provides existence checks.
Spoke with @andrewbranch, we had discussions around
Background
Back in https://github.com/microsoft/TypeScript/issues/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 https://github.com/microsoft/TypeScript/pull/39476, and backed that out in https://github.com/microsoft/TypeScript/pull/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 given file exists. The most we do to leverage this is in @andrewbranch's pull request at https://github.com/microsoft/TypeScript/pull/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 https://github.com/microsoft/TypeScript/issues/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
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
This mechanism
Related work
Relative References in Partial Mode
In https://github.com/microsoft/TypeScript/pull/39476, @sheetalkamat had partial semantic mode try to construct a program out of only relative references. This was backed out in https://github.com/microsoft/TypeScript/pull/40026.
unverified
Go-to-Definition ResultsIn https://github.com/microsoft/TypeScript/pull/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.