Set extensionKind to workspace

[jpogran]

Generally the language server expects documents to have file:// scheme. However based on reports and available telemetry, we can tell there are users attempting to use the language server with other schemes which are not file.

VS Code has two 'types' of extension: UI and Workspace: and they determine what URI gets sent

Workspace Extensions: These extensions are run on the same machine as where the workspace is located. When in a local workspace, Workspace Extensions run on the local machine. When in a remote workspace or when using Codespaces, Workspace Extensions run on the remote machine / environment. Workspace Extensions can access files in the workspace to provide rich, multi-file language services, debugger support, or perform complex operations on multiple files in the workspace (either directly or by invoking scripts/tools). While Workspace Extensions do not focus on modifying the UI, they can contribute explorers, views, and other UI elements as well.

So Workspace extensions will send file:// since they are 'local' to the machine they are running on, while UI extensions will send remote based urls like vscode-remote://.

We need to convince VS Code that our extension is a Workspace only extension. You can either rely on VS Code to choose, or specify the kind yourself via extensionkind. Back when I was looking at #1102 I incorrectly thought we could specify:

"extensionKind": ["workspace", "ui"] — Indicates the extension prefers to run as a workspace extension, but does not have any hard requirements on accessing workspace contents. When using VS Code, the extension will run in VS Code's workspace extension host if it exists in remote workspace, otherwise will run in VS Code's local extension host if it exists locally. When using VS Code for the Web with Codespaces it will run in the remote extension host always (as no local extension host is available).

I thought it would stop it attempting to load on the local machine and force it to load on the remote machine where appropriate. However as we continue to see in this ticket, the extension is left in the local instance and it's up to the user to 'see' that it needs to be installed on the remote instance. The key appears to be 'prefers' and 'no hard requirements'. We 'need' instead of 'prefer' and have 'hard requirements', so we should be more restrictive.

To force VS Code to automatically install our extension in both place and activate the remote one when in a remote contenxt, we need to restrict the extensionKind to workspace:

"extensionKind": ["workspace"] — Indicates the extension requires access to workspace contents and therefore needs to run where the workspace is located. That can be on the local machine or on the remote machine or Codespace. Most extensions fall into this category.

Setting this value is easy, but testing this is easier said that done. We can install from VSIX in both locations, but this does not test VS Code's automatic detection installation mechanism, since we are doing this manually. If you install from VSIX on your local instance, then open a WSL instance it will pull from the Marketplace to install, which has the wrong extensionKind.

To fully test this, you need to follow https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location, which says that we set remote.extensionKind inside our client settings and it will override what the extension manifest has and enable us to test this. The key is that this need to be in the machine setting scope, not your user setting scope:

Once a WSL VS Code instance is opened, installing the Terraform Extension through the Marketplace puts it both locally and in the remote instance. Then when interacting with the Terraform files, the proper paths are used:

So, the final fix should be:

"extensionKind": [ "workspace" ]

You might then question, what about our plans to support the Web host (github.dev or vscode.dev)? Shouldn't setting to workspace mean that we won't be able to run in the Web host? According to https://code.visualstudio.com/api/advanced-topics/extension-host#preferred-extension-location:

If an extension is web-only, it will always run on the web extension host, regardless of the extensionKind setting.

According to https://code.visualstudio.com/api/extension-guides/web-extensions, when we do enable this extension to be web only, it will show up as a web extension and work there.

[dbanck]

Related discussions: #989

[dbanck]

Thank you for providing detailed information on this change!

I think workspace is a safe choice

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.