Vscode: Allow disabling builtin extensions from the command line and persisting the configuration state so that subsequently when vscode is closed and open ithose extensions will still be disabled

[vicapow]

Allow disabling builtin extensions from the command line

[sandy081]

@vicapow Do you want to disable all built in extensions or only specific extension?

[vicapow]

Either would work for our use case. I saw there’s a disable all extensions but that doesn’t actually turn off built in extensions

[sandy081]

Only disabling all built in extensions can be supported but may I know why do you want to do that?

[vicapow]

We have some extensions we need to disable but disabling all would achieve the former.

The use case is to automatically provision laptops with vscode set up to use Flowtype and have Typescript disabled. Having both enabled is confusing

[vicapow]

Any update on this? Is there interest in taking this as a PR?

[sandy081]

@vicapow VS Code has support now to disable extensions from command line. For eg:

code --disable-extension vscode.typescript-language-features

Let me know if this is sufficient for you to build the support you need

[vicapow]

@sandy081 that's awesome! Thanks for the update. Could you clarify what version will be available in? I'm using 1.26.1, which I believe is the latest released version but it does not seem to be working, although it doesn't report any errors.

[sandy081]

It should be available in 1.26.1

May I know What is not working?

[vicapow]

This doesn't seem to persist the extension disablement. It only opens the editor with those extensions disabled.

[sandy081]

@vicapow Yes, it does not persist as these are the options given to that window. But this will be carried for all windows you open from that window.

[vicapow]

Okay, thanks for clarify. With that said, this still doesn't solve for our use case. I've updated the title.

[sandy081]

@vicapow

The use case is to automatically provision laptops with vscode set up to use Flowtype and have Typescript disabled. Having both enabled is confusing

What is the approach you are expecting here? How do you want to provision VS Code with such a set up? Is not it possible for you in the provisioned laptops that will always run code with --disable-extension vscode.typescript-language-features ?

[vicapow]

Specifically I would like to avoid having to wrap the code command if possible. I would expect this to be somewhat error prone and confusing to debug as an end user.

[sandy081]

@vicapow So you need some kind of UI action in VS Code?

[vicapow]

@sandy081 no just some way to persist the state that the built in plugin has been disabled beyond subsequent invocations and instantiations of the editor.

[sandy081]

@vicapow For persisting the state user has to invoke the action some how either through cli or from UI. If that's the case why not open the UI and disable TS extension completely?

[vicapow]

For persisting the state user has to invoke the action some how either through cli or from UI.

The user isn't the one initiation the action, it's our provisioning scripts that run automatically on each users laptop.

We could wrap the code CLI to always run with the proper flags but then if someone opened the app directly, the extensions would no longer be disabled which is inconsistent.

If that's the case why not open the UI and disable TS extension completely?

We could ask users to do this but it's a manual step that can ideally be avoided.

[sandy081]

We could ask users to do this but it's a manual step that can ideally be avoided.

There is a possibility that users can always enable the extension right unknowingly (if they do not know why the typescript extension is disabled). It might be clear for the users as part of the set up of VS code or while using VS Code on a particular workspace to disable typescript extension for that workspace. Disabling as part of the set up might prevent users to use that in other projects which might need TS features right?

[vicapow]

That’s okay. We don’t want to prevent them from using Typescript just make the standard at our company the default.

Once disabled they can always renable it but this would be the exception. Most projects are using Flow and it wouldn’t make sense to have both flow and TS extensions enabled by default.

[sandy081]

I see. Then I do not think this is a requirement to disable an extension by default when VS Code is installed, instead a way to have a project specific disabled extensions. When ever user opens that project, these extensions has to be disabled.

[vicapow]

That would help but we're looking to have these default settings apply to all projects, not just one in particular.

[lxe]

I think the crux of the problem is this:

https://github.com/Microsoft/vscode/issues/15611#issuecomment-349231959

Enabled/Disabled extensions are not stored in workspace settings. Instead it is stored in local storage cache. You can manage them from the extensions view.

It would be nice to have extension disabled/enabled state to be managed from the config file (per workspace via .vscode/settings.json, or per user via the user config)

Also see https://github.com/Microsoft/vscode/issues/15611#issuecomment-287262985

[vicapow]

Having this state be persistable via a user configuration may also address this. We can then modify the default user config to disable these built in extensions.

[sandy081]

We can then modify the default user config to disable these built in extensions.

May I understand more on how you would like to do that? Update settings in each user?

[vicapow]

I don't have much of a preference on how to achieve this but somehow, we would like this state to persist in a way we can provision these machines to default to disable TS builtin extensions for all projects. The idea above was to have some sort of configurable JSON settings somewhere in ~/ that gets read by VSCode so it knows which extensions to disable by default when the app opens.

[sandy081]

I see. I think we can enhance current support of disabling extension from command line to persist the state but it needs new storage support - https://github.com/Microsoft/vscode/issues/58957

[Rendez]

After reading the thread in detail I gathered that we can only open a workspace in VSCode with some disabled built-ins via CLI. I also had the extra challenge of opening a workspace using remote-ssh by default, without having to find recently opened workspaces or projects in the context menu and then open that window that is actually connected to a remote container. Both things can be accomplish from CLI, but it's inconvenient to remember the exact command+arguments, so for our devs I created a Mac App (for instance called IDE) that they can either double click or open with open .vscode/IDE.app.

Inside the App, there's a simple bash file:

#!/usr/bin/env bash

/usr/local/bin/code --folder-uri "vscode-remote://ssh-remote%2B__YOUR_REMOTE_SSH_/some/root/folder/" --disable-extension vscode.github --disable-extension vscode.github-authentication --disable-extension vscode.git --disable-extension vscode.jake --disable-extension ms-vscode.node-debug --disable-extension vscode.php-language-features

There are several ways to create a minimal Mac app. I've also added the VSCode .icns icon file so in the end I have this:

Drag that app to your Dock, opens with the remote-ssh container + some built-ins disabled.