Find Source Definition

[andrewbranch]

This PR adds a new command similar to Go To Definition, but includes locations in JS files that would normally not be considered, excludes all ambient locations, and potentially uses some heuristics to find likely results in JS files that cannot be analyzed with our binder and type checker due to complex module wrappers or other constructs we don’t understand. The process when invoked is:

1. Run go-to-definition on something. If it returns only ambient definitions that are alias targets, or stops at import aliases that couldn’t resolve to anything, continue with next steps. Otherwise, return any non-ambient definitions found.
2. Spin up a temporary project with a single root file, the one in the requesting location, using a new internal compiler setting that prevents module resolution from considering .d.ts files. This lets us resolve to JS files that would normally be “shadowed” by .d.ts declarations.
3. With that project, try go-to-def again, this time skipping any non-alias work and returning best-effort file results for things like imports where the module specifier resolved, but the specific export wasn’t found, or the target file wasn’t even recognized as a module.
4. For any results that were “unverified” (those best-effort file results), see if the requesting location gave us a strong indicator of what the declaration name we’re looking for is (i.e., can we locally resolve to a named import). If so, try a find-all-refs-like text search on the file returned, and from those results get the top-most declarations by that name. (This is obviously highly approximate and needs some vetting as to whether it’s worth doing at all—at the very least, it needs corresponding editor UI to indicate that these results are not much better than a text search. I attempted to filter these declarations further by symbol flags and/or basic type analysis, but that immediately proved unreliable in the face of exports created by factory functions with poor JSDoc annotations.)

I attempted to tack this onto go-to-implementation instead of its own command, but go-to-implementation is extremely weird and did not play nicely with this code. This is much more go-to-definition-like, but I don’t think we can simply augment or replace go-to-definition because we want go-to-def to be super fast and reliable, and I think we don’t want this command returning anything ambient. However, for purposes of gathering public feedback in the meantime, I think I’m going to make a build that replaces go-to-def with this logic. (Otherwise, users would have to use a special build of VS Code in order to send the new command.)

Fixes #6209
Fixes #38474

[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, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary

[amcasey]

One case to consider as we think about how this functionality should be triggered is what ctrl-click should do.

[andrewbranch]

@typescript-bot pack this

[typescript-bot]

Heya @andrewbranch, I've started to run the tarball bundle task on this PR at 34c6cfd. You can monitor the build here.

[sheetalkamat]

Just need to make some of the methods internal

[andrewbranch]

Latest commits

• make _./*|*/add work when _ itself can only be resolved with heuristics
• rename the command FindSourceDefinition, dropping the bound span part of the response as it’s not needed.

[johnsoncodehk]

Could we expose findSourceDefinition for language service API to make it available for LSP?

[andrewbranch]

Unfortunately not—if you look at the implementation here, Find Source Definition happens by orchestrating multiple different language services to call Go To Definition with different module resolution options. What are you hoping to integrate it into?

[johnsoncodehk]

@andrewbranch I hope it can use in embedded typescript language for Vue. (For example: https://github.com/johnsoncodehk/volar-starter/blob/e4f6d9808181f4533811c1aafc4b6afea1f68598/src/components/HelloWorld.vue#L26-L30)

For Go to Definition and Go to Type Definition features, I using getDefinitionAndBoundSpan and getTypeDefinitionAtPosition API of TS language service implemented.

• https://github.com/johnsoncodehk/volar/blob/90d370e82817afe011c8b8bd0a7d645464d45101/packages/typescript-language-service/src/services/definition.ts#L21
• https://github.com/johnsoncodehk/volar/blob/90d370e82817afe011c8b8bd0a7d645464d45101/packages/typescript-language-service/src/services/typeDefinition.ts#L20

I'm also expected a new getSourceDefinitionAndBoundSpan or getSourceDefinitionAtPosition API.

(btw Go to Source Definition is not specification of LSP, so I need to implement it bypass LSP.)

[andrewbranch]

It’s simply not possible to put this functionality on the LanguageService object (or, it would be a significant violation of the LS’s scope of concerns). At minimum you would need to create a second language service (which creates a second Program and TypeChecker!). It would take a bit of work on our end to abstract what I put directly into TS Server into some kind of public API that could be used independently of the project system. This is an experimental API so it’s not going to happen right now, but if you want to open a new suggestion issue for doing this, we’ll keep an eye on it and could discuss some of the design challenges. Thanks!

[johnsoncodehk]

At minimum you would need to create a second language service (which creates a second Program and TypeChecker!).

Actually this is absolutely acceptable 😅, we already have multiple language server & language service instances in order to prevent auto-complete request from being blocked by unfinished diagnostics request. (vuejs/language-tools#393 (reply in thread))

Great to see it experimentally added to the language service API, this feature will be very welcome in the Vue community, it solves some common DX issues in Vue projects (For example: vuejs/language-tools#1226). It doesn't matter if it will be removed anytime in the future, I can adapt the code quickly.

if you want to open a new suggestion issue for doing this, we’ll keep an eye on it and could discuss some of the design challenges.

Of course, thanks in advance!