Document links provided by a custom language server conflict with links provided by VS Code typescript

[Henato]

Issue Type: Bug

We have a use case in our extension (Engine DevTools) that uses a language server to create document links in virtual files.

Some of those links are created for fragments of text inside a require, for example: "require('./foo.js')" or "require('fs')". We would, in this example, turn the fragments "foo.js" and "fs" into links. Those would usually be external links to be handled by a UriHandler in various ways.

This used to work for virtual files, but recently, links inside a require started to conflict with the links provided by typescript by default. Right now, VS Code tries to open both links.

Steps to reproduce:

1 - Clone and debug the extension sample in https://github.com/Henato/doc-link-sample.
2 - While debugging, run the commands "MemFS: Setup Workspace" and then "MemFS: Create Files".
3 - Open testExternalLinks.js and ctrl+click on '.foo.js'. It should open the desired file and also throw an error.
4 - Close foo.js and return to testExternalLinks.js.
5 - In testExternalLinks.js, ctrl+click on 'fs'. It should open both 'foo.js' and the d.ts for the "fs" module.

Stack for the error in step 3:

[2021-11-04 08:58:36.597] [renderer8] [error] Error: Unable to resolve filesystem provider with relative file path 'memfs:foo.js'
    at withProvider (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:610:11090)
    at withReadProvider (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:610:11389)
    at wi.readFileStream (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:610:16266)
    at f.doRead (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2365:41859)
    at f.readStream (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2365:41568)
    at f.readStream (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2365:50536)
    at Ji.resolveFromFile (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2354:98250)
    at Ji.doResolve (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2354:96288)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async a.resolve (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2365:36600)
    at async Sa.doResolveAsText (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:1738:85537)
    at async i.setInput (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2319:142104)
    at async h.doSetInput (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2319:34301)
    at async h.doOpenEditor (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2319:32701)
    at async h.openEditor (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2319:32349)
    at async vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2521:16907
    at async b.doOpenCodeEditor (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:1297:137258)
    at async q._openReference (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:781:32018)
    at async q._onResult (vscode-file://vscode-app/c:/Users/renat/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:781:31747)

There is also a testInternalLinks.js file, which is similar but uses regular URIs as targets for the links instead of external links. In this example, the links behave as expected, with both links only opening the foo.js file.

It is important to note, though, that even regular ("internal") links could fail and have the same behavior as external links if:
1 - The methods from the MemFS file system provider are async, or;
2 - The targets for the links are lazily resolved in connection.onDocumentLinkResolve, in the language server.

All the examples mentioned above were also tested on insiders, which rendered equal results for internal links, but completely failed when opening external links, throwing the error:
"Unable to resolve text model content for resource vscode://nginstack.memfs-doclink-error/memfs/foo.js"

Is there any workaround that we could implement to fix this behavior, or is there something we are doing wrong in any of the examples above?

VS Code version: Code 1.61.2 (6cba118, 2021-10-19T14:57:20.575Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 1800)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	7.91GB (1.28GB free)
Process Argv	--crash-reporter-id 0a03759f-52f2-4671-9862-a222911d7d63
Screen Reader	no
VM	0%

Extensions: none

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30384386
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
vsccppwtct:30382698
bridge0708:30335490
pygetstartedt3:30385195
dockerwalkthru:30377721
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsqsis200cf:30386380
vsaa593:30376534
vssld246cf:30386378

[mjbvz]

The TS extension doesn't have a document link provider so it sounds like you are talking about definition links? Is your extension using DocumentLinkProvider or DefinitionProvider?

[Henato]

Hi @mjbvz, thanks for responding

I'm not using any of those. The extension is providing the links through a language server, similar to what
this sample does:
https://github.com/microsoft/vscode-extension-samples/tree/main/lsp-sample

This file implements the logic behind the link generation:
https://github.com/Henato/doc-link-sample/blob/master/server/src/server.ts

And this file, lines 63 to 83, configures and starts the language server:
https://github.com/Henato/doc-link-sample/blob/master/client/src/extension.ts

Having said that, I've also tested using a DocumentLinkProvider instead of a language server, but it behaves the same way, it didn't fix my problem.

[Henato]

Hey @mjbvz, this issue might need further attention.

@Henato, you can help us out by closing this issue if the problem no longer exists, or adding more information.

Hello @mjbvz, the problem still exists, any updates?
Is there any information I could give in addition to my response back in November?

[mjbvz]

This is a duplicate of #81520

I'll check in a fix for TS resolving the wrong path but we still plan on returning a definition. Until #81520 is fixed, this means both the definition and document link will be invoked on click

@Henato One other note: in your sample, you hardcode the scheme vscode: for the external uri. However in insiders, we instead use vscode-insiders:. You should use the value of vscode.env.uri for the scheme (off the top of my head I don't know how to get this on a language server but it should be possible)