Set extensionKind in package.json to support Remote Development

[mjbvz]

Hi, I'm on the VS Code team. We recently released support for Remote Development and I noticed that your may extension need a small change to ensure users have a good experience when using it remote workspaces.

What is the issue?

To make remote development as transparent as possible to users, VS Code distinguishes two classes of extensions:

• UI Extensions: These extensions make contributions to the VS Code user interface and are always run on the user's local machine. UI Extensions cannot directly access files in the workspace, or run scripts/tools installed in that workspace or on the machine. Example UI Extensions include: themes, snippets, language grammars, and keymaps.

• Workspace Extensions: These extensions are run on the same machine as where the workspace is located. When in a local workspace, Workspace Extensions are run on the local machine. When in a remote workspace, Workspace Extensions are run on the remote machine. 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 workspace (either themselves or by invoking scripts/tools).

You can find more details about this architecture here.

VS Code currently infers that your extension is a Workspace Extension. This means that users who have your extension installed must also install it to the remote in order to use it in remote workspaces. I believe that your extension should probably be a UI extension instead. That way your extension will always be enabled for users who install it, even if they open a remote workspace.

How do I fix this?

To tell VS Code that your extension is a UI extension, just add "extensionKind": "ui" to your extension's package.json.

UI Extensions always run on the user's local machine, even when they open a remote workspace.

I'll submit a PR that does this. Please let me know if you have any questions or concerns about the issue. We've also put together a guide to help you test your extension in remote workspaces

PS: As a temporary workaround for a few popular extensions, we've automatically added your extension to an internal whitelist so that is always treated as a UI extension

[gandarez]

Merged, thanks.

[alanhamlett]

No, it's not a UI extension as it needs access to files on the filesystem.

[alanhamlett]

@mjbvz is that correct, that since the extension needs to read the current file contents, and the contents of surrounding folders, that it must be workspace type?

[vilicvane]

@alanhamlett Just encountered this problem, WakaTime is not working with remote development now (and sadly no option to install on remote, possibly caused by the incorrect "extensionKind").

[alanhamlett]

@vilic can you add this to your settings and see if it works:

"remote.extensionKind": {
    "WakaTime.vscode-wakatime": "workspace"
}

[vilicvane]

That helps the installation on remote, but then I get this:

[Extension Host]
[WakaTime][DEBUG] Sending heartbeat: python3 /root/.vscode-remote/extensions/wakatime.vscode-wakatime-2.0.9/wakatime-master/wakatime/cli.py --file /root/projects/remote-dev/Dockerfile --plugin "\"vscode/1.34.0-insider vscode-wakatime/2.0.9\"" --alternate-project remote-dev

[Extension Host]
[WakaTime][ERROR] python3: can't open file '/root/.vscode-remote/extensions/wakatime.vscode-wakatime-2.0.9/wakatime-master/wakatime/cli.py': [Errno 2] No such file or directory

[Extension Host]
[WakaTime][ERROR] Error: Command failed: python3 /root/.vscode-remote/extensions/wakatime.vscode-wakatime-2.0.9/wakatime-master/wakatime/cli.py --file /root/projects/remote-dev/Dockerfile --plugin "vscode/1.34.0-insider vscode-wakatime/2.0.9" --alternate-project remote-dev
python3: can't open file '/root/.vscode-remote/extensions/wakatime.vscode-wakatime-2.0.9/wakatime-master/wakatime/cli.py': [Errno 2] No such file or directory

[Extension Host]
[WakaTime][ERROR] Unknown Error (2); Check your /root/.wakatime.log file for more details

And .wakatime.log is not created. I guess installing python3 might help, will try that later. Misread the error message.

[vilicvane]

It seems that file wakatime-master.zip exists but directory wakatime-master does not.

[alanhamlett]

It seems that file wakatime-master.zip exists but directory wakatime-master does not.

Relaunching VS Code causes the WakaTime extension to extract that zip file into the extensions/wakatime.vscode-wakatime-2.0.9/wakatime-master folder.

[vilicvane]

@alanhamlett Seems that I just keep getting 0 length wakatime-master.zip file. Checking connection issues.

[vilicvane]

Looks like that my issue was caused by VS Code applying local proxy settings (implicit imported from system) to the remote extensions. microsoft/vscode#60773

[vilicvane]

@alanhamlett So now basically it's working. There's some issue opening WakaTime dashboard from status bar though (Error: spawn xdg-open ENOENT). I have Live Share extension installed on remote but it seems to handle opening browser locally well.

[gandarez]

@vilic do you have Mac or Linux? if Mac, which OS version?

[vilicvane]

@gandarez local Windows 10 with remote Ubuntu 18.04

[gandarez]

@gandarez local Windows 10 with remote Ubuntu 18.04

you mean you're using a Live Share connected in a remote machine with ubuntu, right?

[vilicvane]

@gandarez Sorry for getting you confused. I was just saying the Live Share (installed remotely) button can open local browser successfully while WakaTime can't:

I am ussing Remote-SSH to connect (there's nothing to do with Live Share).

[gandarez]

For me Live Share does not open any link on local browser.

[mjbvz]

@alanhamlett It depends on which files you are accessing and how you are doing this. If you are reading files from the workspace (and not using the vscode apis to do this) then you must be a workspace extension

I'll remove your extension from the whitelist so its entirely up to you to decide where it should be run

[alanhamlett]

Thanks! It needs to be a workspace extension so I'll add the necessary config changes.

[alanhamlett]

Fixed in v2.1.0.

[alanhamlett]

and not using the vscode apis to do this

@mjbvz are there vscode apis that allow a UI extension to read the contents of an opened file on a remote workspace?

[mjbvz]

The TextDocument and VS Code fs apis support remote resources. Just avoid using node apis

[IgnisDa]

What is the current status of this issue? I have wakatime added to "always installed extensions" in my VSCode settings. Every time I rebuild the container (which is a lot), I have to re-enter the API key.

One possible solution as (partly) suggested in #130, would be allow Wakatime to read the API key as an environment variable and somehow pass the wakatime API key to the container. For example (in .devcontainer/devcontainer.json):

{
// other stuff
   "remoteEnv": {
       "WAKATIME_API_KEY": "${localEnv:WAKATIME_API_KEY}"
   }
}

Then wakatime can first check if WAKATIME_API_KEY environment variable exists and try to authenticate with it. If it does, then all's well and it can continue to initializing, otherwise it will prompt the user for the API key as per normal. Here is where I found the ${localEnv:WAKATIME_API_KEY} syntax.

This has the additional benefit of not causing any problems for those people who do not use wakatime. For them the WAKATIME_API_KEY environment variable will simply not exist on the host machine. So this file can checked into version control without any potential of breaking other's build environments.

I think we should keep it up to the users to ensure that the WAKATIME_API_KEY environment variable exists on the host systems for this to work correctly.

@alanhamlett What do you think about this? I can try making a PR for this too.