Default search service extension - follow file link doesn't work

[Abdallatif]

When using the @codingame/monaco-vscode-search-result-default-extension and open search results in editor, then hover over a file name and click on the follow link

The following error appears:

In the console, it shows the following error:

Uncaught (in promise) Error: Unable to read file '/test.js' (Error: Unable to resolve nonexistent file '/test.js')
    at VHe.restoreReadError (main.common-7DLNmK_d.js:1427:23935)
    at VHe.doReadFileStream (main.common-7DLNmK_d.js:1427:23642)
    at async WHe.doRead (main.common-7DLNmK_d.js:1427:78870)
    at async WHe.readStream (main.common-7DLNmK_d.js:1427:78625)
    at async ame.resolveFromFile (main.common-7DLNmK_d.js:1427:57239)
    at async ame.resolve (main.common-7DLNmK_d.js:1427:55401)
    at async FHe.doResolve (main.common-7DLNmK_d.js:1427:73374)
    at async sKe.doCreateReferencedObject (main.common-7DLNmK_d.js:1734:6398)
    at async Xjt.acquire (main.common-7DLNmK_d.js:29:3253)
    at async oKe.createModelReference (main.common-7DLNmK_d.js:1734:8629)

I tried to do some debugging and find the core issue, my guess here is that the ~ is being ignored while it should be converted to the workspace uri.

I also found (by manually changing the editor search results) that if we remove the ~/ from the file path, vscode would be able to locate the file correctly.

[CGNonofr]

Thanks for the report!

Once again, it's a bug in VSCode (or a combination of bugs) that doesn't affect VScode in the way it's used but does impact monaco-vscode-api

Explanation:

• in web mode, VSCode try to guess the local user home based on what it has access to. It there is a remote connection, it takes the remote user home but if not, it take the first workspace folder as user home, or the folder containing the workspace configuration
• in web mode, the search result default extension is not able to resolve the user home directory because the VSCode extension api doesn't allow it. So it relies on process.env.HOME || process.env.HOMEPATH || '' but process.env is polyfilld in web mode by the webpack build and replaced by an empty object

So, in the demo, the user home directory is detected by VSCode as /tmp while it's detected as / by the search result extension

It works in VSCode.dev because there is no way to start with a local open folder (you can only open it later)

So a workaround can be to do the same as in vscode.dev: create an empty workspace THEN add your folder in it when the services are initialized

[CGNonofr]

#373 will allow to manually configure user home directory, setting it to anything else (/ is fine) will workaround your issue

[Abdallatif]

Awesome, thanks a lot for fixing this 🙏 I'll close the issue since it's fixed now.

[buglessbuild]

@CGNonofr I’m facing the exact same issue when I try to use the “peek definition” feature. I’m using monaco editor@7.0.7 from this repo and typefox/monaco-languageclient@8.7.0.

It adds ~/ at the beginning of the file and because of that it’s not able to access the file and throw the error. I don’t think we can configure the user home using initServices function. Can you please tell me how can I configure the user home and resolve this issue?

[CGNonofr]

@CGNonofr I’m facing the exact same issue when I try to use the “peek definition” feature. I’m using monaco editor@7.0.7 from this repo and typefox/monaco-languageclient@8.7.0.

I don’t think we can configure the user home using initServices function. Can you please tell me how can I configure the user home and resolve this issue?

It would need an update of the TypeFox libraries then @kaisalmen

[kaisalmen]

@CGNonofr and @shivam6543 yes, this need to be fixed. I started enhancing this on this branch: https://github.com/TypeFox/monaco-languageclient/tree/oct-vscode-web I will extract it and introduce the Environment parameter.