Suggestion: Allow extension packs to not be defined by dependencies

[chrisdias]

An "extension pack" is generally a curated collection of extensions targeted at a specific scenario. The Azure extension pack installs 10+ extensions all related to Azure. As a user I might be interested in 8 of the extensions and want to uninstall the rest.

However, it is hard to uninstall a subset of the pack because those extensions are defined as dependencies of the extension pack extension.

Suggest that we introduce a mechanism where I can define a collection of extensions (an extension pack), but they are not dependencies of the root extension. That way I can (as a user) install an extension pack for Python or Azure or [fill in the blank], see all the cool extensions, and then manage individual ones more easily.

[sandy081]

I do not think we can go away from using dependencies for extension packs as it has become a sort of API. Your requirement looks like asking for optional dependencies ?

[akaroml]

I'd like to echo this one. #48873 was logged against the similar issue.
What we'd like to have is to have all dependency extensions installed but not loaded when the pack extension is loaded as a normal extension.

[tboby]

My use case for this would be a recommended language colorizer. Most users will be happy with the language colorizer I provide, but I don't want to force them to use it if they prefer another.

My plan was to have the colorizer as an extensionDependency, but it sounds like that would override any other extensions.

[chrisdias]

Here is another scenario where the current model is problematic:

• Install the Node Pack for Azure extension
• Reload
• In the Extension Viewlet, click on the ... menu and choose Disable all installed extensions

Result:

• For a number of the extensions, I'm prompted to uninstall the dependencies as well (the Azure Account extension, which is a dependency of the App Service extension):

• Once done, I get three errors:

But they are actually disabled on reload.

[sandy081]

@chrisdias Above scenario is a bug. Please file a separate issue for that.

[chrisdias]

ok, filed: #49929

[AvinZarlez]

+1 to this.

I have an extension pack, and people like portions of it but want to be able to disable one or two of the extensions if they chose not to have them.

There should be an "optional dependency" system instead? Perhaps installs by default and/or asks, but then allows disabling/uninstalling?

[toxikman]

Agree - I too would like to see optional dependencies for packs.

[akaroml]

Good to see it's in the June plan. Can't wait!

[sandy081]

Sorry could not make this in June. Deferring to July.

[sandy081]

Introducing an optional property to extensionDependencies. An extension can be added to extension dependencies as an optional dependency. In such a case,

• the optional dependency extension will be installed while installing the dependent extension.
• the optional dependency extension can be uninstalled / disabled / enabled independent of the dependent extension.
• the optional dependency extension will not be activated automatically while activating the dependent extension.

The way to define an optional dependency would be as follows

"extensionDependencies": [
     {
          "id": "pub.a",
          "optional": true
     },
     "pub.b" // mandatory
]

[bnb]

As the maintainer of VS Code for Node.js - Development Pack, I'd like to give a HUGE +1 to this.

If this were shipped, it would enable me to ship a bunch of additional extensions as "optional" – Node.js developers are pretty diverse in their interests, and it would be great to be able to send a larger additional set of optional extensions over the wire.

[sandy081]

Took a different solution than what I proposed previously (introducing an optional property). We though mixing extension pack and extension dependencies is confusing and does not express what we want to do.

Similarities between Extension pack and Extension dependencies:

1. Extensions are installed/enabled together

Differences between Extension pack and Extension dependencies:

1. Activation: Extension dependencies should be activated along with the dependent extension but not for Extension pack
2. Uninstall/Disablement: Dependencies cannot be disabled when the dependent is not. But a packed extension can be when the extension pack is not.

Hence introduced a new property called extensionPack in package.json for defining an extension pack where you can provide extensions that can be installed together.

"extensionPack": [
     "pub.a",
     "pub.b",
     "pub.c"
]

[akaroml]

This solves our problem perfectly. Thank you so much.