Load/download extension using extensions.json adjacent to settings.json

[JasCodes]

I think it makes sense to move extensions to extensions.json for following advantages.

• Easy to share and sync
• Workspace specific extensions
• Allow users to create extensions collection which user can enable or disable as collection
  e.g csharp collection in extensions.json file will have on csharp related extensions and can be disabled in workspace extensions.json so unnecessary extensions are not loaded

Thx

[JasCodes]

@sandy081 @joaomoreno

[shanalikhan]

This makes sense
It will also solve this issue : #14444

[roblourens]

I don't understand what you're asking for, we support an extension.json file already.

[JasCodes]

Hey @roblourens

I am new to IDE. I didn't came across extension.json either at location C:\Users\user\.vscode-insiders or C:\Users\user\AppData\Roaming\Code - Insiders\user

So it will be awfully nice of you to point out if I am missing something.
Thx

PS: @shanalikhan also have similar year old issue #14444

[roblourens]

We a have a couple features that address this:

• Workspace recommended extensions, via a extensions.json file in your .vscode/ folder: https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions
• Extension Pack extensions let you share and download a bundle of extensions.

Hope that helps!

[JasCodes]

Hey @robertohuertasm
That was extremely helpful information.

But I still feel its more inline with the design pattern of light weight text editors such as vscode to save all settings in json file including user-wide extensions.

Let me try to rephrase and update my proposal.

• In user folder C:\Users\user\AppData\Roaming\Code - Insiders\user create extensions.js and environment.js

• extensions.js should contain list of all extensions and there enabled status; this is more in line with design pattern and aggregate all vscode configrations in one folder.

• environment.js is optional file where you can create collection of extensions. Lets say we have csharp, misc and cpp environment. Each can have collection of extensions that are available. Benefit of this is one can enable/disable any environment. Lets say you enabled misc and cpp in settings all csharp extensions will be not loaded but union of misc and cpp extensions will be loaded.

Let me know if I was able to explain the proposals decently ; I do strongly feel about extensions.js at user level to manage state of extensions is inline with design pattern.

Thx

[roblourens]

Thanks for the details. We try to design the extension APIs so that the user doesn't need to do a lot of manual management like that - I have lots of extensions installed that are only useful in certain file types or workflows, but I've never needed to enable/disable them individually. It is possible to disable them for a certain workspace (by clicking the gear in the extensions viewlet) but I don't think that controlling it with a config file is necessary.

Instead, if there are extensions that need to be enable/disabled really often, we should figure out why that is and either file issues on the extension, or change the extension APIs so that they don't interfere.

[JasCodes]

Well json configs are for nerds and that what vscode copied from success of sublime. This allows you to check them in git, share and expand on each others work.

Anyways you already have UI for settings.json but still have file for it which I can sync accross platforms easy. Same true for extensions, people who don't wanna use extensions.json file; for them you already have UI; I am just purposing the using json as store instead of internal store.

Thx

[roblourens]

Got it. I just realized this is also tracked in #15442, there has been some other discussion about it if you check the other linked issues too.