Vscode-project-manager: Enable/Disable extensions for projects

[muuvmuuv]

Some time ago I tried reach out to VS Code team to allow projects to have an extensions file (in .vscode folder) where I can say which extensions I want to have enabled or disabled, sadly it got rejected.

I work with different type of projects, some requires PHP extensions, some have only NodeJS/JavaScript, TypeScript, Go and so on. My idea was to have a file or a config section somewhere where I can say in which projects/folder I want to have extensions enabled or even disabled in some cases. This would reduce the startup time heavily in my case.

I thought about ways how this could be done and now my idea is to have my projects managed together with my extensions I want to have enabled __for__ my projects. So the best solution is to combine them in the project manager where a new object extensions would allow extension to be enabled/disabled. I don't know if this is possible but I think this is something that belongs here.

[muuvmuuv]

This is what I found in the API:

https://github.com/Microsoft/vscode/blob/master/src/vs/vscode.d.ts#L8921-L8949

[muuvmuuv]

Something like this I guess.

const projects = [
  {
    enabled: true,
    name: 'Test',
    rootPath: '$home/Test',
    group: 'testings',
    extensions: {
      'ms-vscode.vscode-typescript-tslint-plugin': true,
      'rebornix.ruby': false
    }
  }
]

projects.forEach(({ extensions }) => {
  Object.keys(extensions).forEach((extName, active) => {
    const ext = vscode.extensions.getExtension(extName)
    if (!ext) {
      // not a known extension
      return
    }
    if (active) {
      ext.activate()
    } else {
      // deactivate extension here
    }
  })
})

[alefragnani]

Hi @muuvmuuv ,

Well, this is not the extension's original idea, which is simply _to give you easy access of your favorite projects_, but I agree this is a great addition to the workflow.

But I'm wondering, why VS Code does not support it natively (using a local file), just like it does for Extension Recommendations (.vscode\extensions.json file). I mean, it already supports Enabling / Disabling extensions _per workspace_, so you already have that. The only difference is that it does not use a _local file_ to store the enabled/disabled extensions, but probably uses the VS Code internal storage (workspace based).

I don't know _when_ you reach out VS Code team asking for this, but maybe it was prior this Enable/Disable extension per workspace feature being implemented (I guess it happened last year). If that is the case, I think if you ask them again, it could be natively supported using .vscode\extensions.json file.

My main concern about adding this to the extension (besides not being it's original idea) is because some extensions requires _reloading the workspace_ when you enable/disable it. I'm not sure _why_ it does happen, and what could be done to detect, in order to avoid/warn the user. Without this issue, as you already commented, it's doable :-).

Hope this helps

[muuvmuuv]

Ah I see some people already asked that again in VSCode, haven't checked that before. So hopefully they will add this soon ^^ And yes it was before the __Extension Recommendations__, don't get it why they implemented this, never have used this because it's so uncomfortable to use.

I just thought it would be a great combination with projects/workspaces in one destination. Anyway I still think this extension should be natively supported 😆 Code is on a good way to get a nice IDE but Project Management is missing and I really don't know why they don't want it.

https://github.com/microsoft/vscode/issues/40239

[contributorpw]

I can't understand how does this feature would binding to the current project?

I think it would be great to add parameters for exec the code to the project manager settings file. For an example:

[
  {
    "name": "google_spreadsheets_chat_bot",
    "rootPath": "/raid/user/gitlab.com/blah-blah ",
    "paths": [],
    "group": "",
    "enabled": true,
    "args": "--extensions-dir /home/user/yada-yada"
  }
]

It would let us to use more flexible options. Using exported variables would be great too. "before runs triggers" are appreciated too.

[alefragnani]

Hi @oshliaer ,

Thank you for your suggestion, but to switch between projects, the extension does not use code command line but the openFolder command (VS Code API) and it does not provide _args_ to add.

I'm not sure such extensibility is possible, because some of the command args may define _how VS Code will open_, so I guess to accomplish such feature, it would indeed need to use code command line args. It's not something that I would like to _bring back_ (at the early days of the extension, it worked this way), but I wouldn't say _it won't happen_ 😄 . I'll move it to its own issue.

Hope this helps

[alefragnani]

@muuvmuuv ,

It appears my concerns about _enabling/disabling extensions_ were real. A new extension called Profile Switcher already has a few open issues about it:

https://github.com/aaronpowell/vscode-profile-switcher/issues/

I'll keep watching its evolution, but if these errors didn't get fixed, I'll cancel the issue.

Hope this helps

[muuvmuuv]

Sounds reasonable for me. The extension looks good but I don't want to have this separated if it's possible 😄

[alefragnani]

Hi @muuvmuuv ,

I did take a look at Profile Switcher extension to see it evolution and just noted that it does not really _ disable/enable_ extensions but uninstall/install instead. That's not something that I would like to do, because installation is not a _workspace_ feature.

For now, there is no API to deactivate extensions, just activate. For some reason the VS Code team decided to store this info in internal storage, not settings.json/extensions.json.

I'll keep looking

[alefragnani]

Depends on https://github.com/microsoft/vscode/issues/84997

[alefragnani]

Just recently (https://github.com/microsoft/vscode/issues/84997#issuecomment-574910685) the dependency issue has been moved to “Backlog Candidate” by the VS Code team, which means it has 60 days to receive enough attention (upvotes), otherwise it will be closed.

So, for those of you interested in this issue to be possible, go to the VS Code repo and upvote.

[contributorpw]

There are 12 :+1: now.