Vscode: Provide access to VS Code API in extension uninstall lifecycle hook

[GabrielBB]

• VSCode Version: 1.20.1
• OS Version: Windows 10

Steps to Reproduce: Add this events to an extension code:

export function activate(context: vscode.ExtensionContext) {
vscode.workspace.getConfiguration().update('test', 'some text', ConfigurationTarget.Workspace);
}

export function deactivate(context: vscode.ExtensionContext) {
    vscode.workspace.getConfiguration().update('test', '', ConfigurationTarget.Workspace);
}

When it activates it updates but on deactivation it doesn't work. Im debugging and the code is running but with no effect. I also tried with ConfigurationTarget.Global.

[GabrielBB]

Well, for now, I’m gonna put the settings as global and remove them after plugin uninstall thanks to this: https://stackoverflow.com/questions/49205613/how-to-execute-code-when-user-uninstalls-your-vscode-extension/49211345#49211345

[GabrielBB]

I couldn't get it to work after extensions uninstall because the package "vscode" cannot be found when the uninstall hook executes my JS file with node. I read that this is the normal behavior, i cannot use the vscode api in the uninstall hook then...

[sandy081]

@GabrielBB Can you return the promise during deactivate and try?

export function deactivate(context: vscode.ExtensionContext) {
    return vscode.workspace.getConfiguration().update('test', '', ConfigurationTarget.Workspace);
}

[GabrielBB]

@sandy081 Just tried it, doesn't work. What i noticed debugging is that VS Code is not even waiting for the event code to fully execute. When i put a breakpoint in the return, it only lasts like 2 seconds, then the thread is getting killed or something. So for now, we cannot clean settings in deactivation nor in uninstall (https://github.com/Microsoft/vscode/issues/35006#issuecomment-372384164).

[sandy081]

What i noticed debugging is that VS Code is not even waiting for the event code to fully execute. When i put a breakpoint in the return, it only lasts like 2 seconds, then the thread is getting killed or something.

@alexandrudima Are you aware of this?

[GabrielBB]

@sandy081 @alexandrudima I forgot to tell that this is happening while changing workspaces or closing VS Code. I don’t know about other deactivation scenarios, like when closing a file with an extension that was activated when that file was opened

[alexdima]

This is as designed. The deactivate method is a place to clean up OS resources (kill spawned processes, etc.). It is not supported to initiate configuration edits and other such things. The reason is that the window renderer process does not wait for the extension host process. It goes down as soon as the user presses x.

[GabrielBB]

@alexandrudima Understood. Well, i don't have options then since the uninstall hook can't access the vscode api, basically developers can add settings but can't clean them (at least they clean it when a specfic file is closed) For now i'm manually going to the user settings json in your file system and editing it when the extension is uninstalled like this: https://github.com/GabrielBB/vscode-lombok/blob/master/src/uninstall.ts (Dirty solution lol) I will open a feature-request for vscodeapi in uninstall hook

[sandy081]

@GabrielBB Makes sense. Please update the current issue to support for such api in uninstall hook.

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[joaomoreno]

An alternative is to declaratively mark settings which are meant to be deleted from the user settings file on uninstall.

[JimiC]

Throwing an idea here. How about moving the npm uninstall script hook into the extension context, much like

export function uninstall(context: vscode.ExtensionContext) {
  // Execute uninstall code which has access to `vscode` API
}

[sandy081]

@JimiC This does not help to update the configuration.

[JimiC]

@sandy081 How come? Wouldn't the access to vscode API give the ability to perform vscode.workspace.getConfiguration().update?

And to be more clear, the idea is to have the uninstall function in the same way we have activate and deactivate, which both have access to vscode API.

I know that this will require that vscode will have to load the extension which gets uninstalled and this maybe something you don't want to happen. This issue will have to get tackled.

[sandy081]

@JimiC I thought you just want to pass the context.

And we cannot pass complete VS Code API as it has too many methods which are not supposed to run during uninstall.

If it is for clearing settings, why not VS Code do it out of the box when an extension is uninstalled like in comment

[JimiC]

That would be even better. That will make me delete a lot of code and testings.

[JimiC]

I hope you guys consider also that we are writing in the globalState too.

[GabrielBB]

I also agree with the solution by @joaomoreno .

[oreporan]

any updates on this?
My extensions creates some workspace settings which I need to cleanup in case of uninstall

[GabrielBB]

Any updates?

[sandy081]

No updates yet.

[jdoklovic]

Maybe I'm missing something, but shouldn't it be possible and fairly simple to add an uninstall hook with the exact same signature of the activate hook in the main extension file, then when a user clicks the uninstall button for the extension, simply await {extension}.uninstall(context) BEFORE actually doing the uninstall?

I'm not sure users understand that when they uninstall an extension, all of their user settings, workspace settings and globalState for the extension still exists.

[JimiC]

The thing is that the uninstall hook works a bit unconventional.

From my observations the lifecycle goes like this:

1. User clicks uninstall
2. Extension marked as "obsolete"
3. On vscode restart uninstall script gets executed

On step 3 vscode can't call the extension as it's not loaded yet or it doesn't exist.

Note: uninstall script gets executed also when the extension gets updated simply because the previous version is marked as obsolete.

[jdoklovic]

Right, but why not call extension.uninstall() when the user clicks uninstall to give the extension a chance to run cleanup routines, THEN mark it as obsolete and continue like it does today?

[GabrielBB]

@jdoklovic +1000

[jramsay]

@jrieken: Is there currently a way to determine if an extension deactivate() is due to, or happens after, an uninstall?

For Live Share I'm interested in disposing our vsls-agent.exe immediately after the _uninstall_ Live Share extension button is clicked. I could force kill our agent process on deactivate() if I could determine it was due to an uninstall. We keep our agent alive after reload for a few seconds so this impacts proper cleanup and can cause issues if a user attempts to reinstall the extension immediately after an uninstall (in this scenario the vsls-agent.exe in the target install path would still be locked).

[jrieken]

afaik there is nothing to observe uninstall but a ping for @sandy081 for more insights

[sandy081]

vscode:uninstall script is for post uninstall hook but this is called when extension is removed. We do not call it immediately after uninstall because the extension could be running on other windows.

[warrenbuckley]

OK seems I have a related/same issue reported here - https://github.com/microsoft/vscode/issues/103688 by attempting to get some insight into debugging or logging output to understand what is going on.

Current attempt is to write the process.env object to a JSON string on disk and I have noted that there are some VSCode specific ENV variables. So the uninstall code being executed is aware its being run from VSCode, with this being the case is it possible to get access to the vscode API in the uninstall script?

ENV Variables available in vscode:uninstall hook

"VSCODE_CWD": "C:\\Users\\warre\\AppData\\Local\\Programs\\Microsoft VS Code Insiders",
"VSCODE_IPC_HOOK": "\\\\.\\pipe\\9260d5401ef6df01ef46190fa2e30e66-1.48.0-insider-main-sock",
"VSCODE_LOGS": "C:\\Users\\warre\\AppData\\Roaming\\Code - Insiders\\logs\\20200731T120256",
"VSCODE_NLS_CONFIG": "{\"locale\":\"en-us\",\"availableLanguages\":{},\"_languagePackSupport\":true}",
"VSCODE_NODE_CACHED_DATA_DIR": "C:\\Users\\warre\\AppData\\Roaming\\Code - Insiders\\CachedData\\c9a2f78283b6e5ef708fb8869e2a5adaa476e42f",
"VSCODE_PID": "5440"

[vscode-triage-bot]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!