Persist an extensions manifest file

[Tyriar]

See #7035 & #3884

Persist an extension manifest file extensions.json that lists all extensions installed and other relevant data (whether they're disabled?), on launch the list could be checked and automatically install extensions. This would help enable:

• Roaming on Windows Revisit VS Code folder structure for app data, settings, extensions #3884
• More logically cache and config files on Linux, also Revisit VS Code folder structure for app data, settings, extensions #3884
• Allow extensions or external programs to sync extensions more easily

This is a soft dependency for #3884

[joaomoreno]

Not a big fan of this. From my experience, multiple truths never work nicely.

Some problems I see:

• Would an unsuccessful extension uninstall remove it from the list?
• Extensions that fail installing will keep Code busy always trying to install them.
• Installed extensions that suddenly have dependencies in newer versions. Do we expect Code to install those too? And update the list?
• What would it mean to the list if the user would side load an extension? And what about manually removing the extension?

[Tyriar]

Making this the sole source of truth would probably be ideal, the rest seem to be error handling and implementation details. Something like this is necessary if we want to allow extensions to work in a roaming environment as the user data dir and the extensions themselves are too big to roam.

Would an unsuccessful extension uninstall remove it from the list?
I guess it would depend on when unsuccessful was; bad internet connection: no, extension doesn't exist: maybe

Extensions that fail installing will keep Code busy always trying to install them.
Only if we allowed it.

Installed extensions that suddenly have dependencies in newer versions. Do we expect Code to install those too? And update the list?
If necessary, I don't see why it would need to change from what's done now. If it's based on local storage this would just mean moving the state to a file, if it's based on the dir then shifting the source of truth to be the file.

What would it mean to the list if the user would side load an extension? And what about manually removing the extension?
Side loading: Good question 😄
Manually removing: The user could remove it from the file.

To be clear, this is just a suggestion to solve the problem of allowing extensions to roam efficiently (nice to have) and a clean division of cache and config (not as important). Currently we roam pretty much everything (include user data dir) except for extensions. We could just accept this as a limitation but it's not ideal.

[JasCodes]

Hey Guys

Any movement on this?

Thx

[shanalikhan]

Similar issue i opened Year ago for my settings sync.
#14444

If a extension.json file is created and API to import the file is provided such that in file it should be written for each extension that it is disabled or enabled. It will fulfill that issue.

[NotWearingPants]

Hey, any updates on this issue?
Thanks

[truongnmt]

There is a very good extension to sync all settings. Tested! Work perfectly!

https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

[lxe]

I work on Flow and TypeScript projects as a part of my day-to-day. The ability to define which extensions to enable, and which to disable in .vscode/settings.json is a highly coveted feature. Please make this a thing.

[JasCodes]

Ah man.. its so obvious; after doing so wondful job on vscode Microsoft will still do that little thing that will make me pull all my hair out!!!

[leolcao]

+1

[alexhass]

Can you guys implement this to solve the roaming profile issues finally, please?

[zzzachzzz]

Sublime's Package Control, or a plugin manager in Vim for example both read / write from human readable config files, listing installed packages / plugins / extensions. Many devs, myself included, use a Git repo to store these configs. It would be nice to be able to fully recreate a VSCode environment from config files, without requiring us to use VSCode's Settings Sync.

[arkq]

@zzzachzzz see this: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#your-extension-folder

"To load an extension, you need to copy the files to your VS Code extensions folder [...]"

The way to exploit this in dotfiles is to use local extension pack as a sync point.
See: https://github.com/Arkq/dotfiles/blob/master/.vscode/extensions/arkq.dotfiles-1.0.0/package.json

[Tyriar]

This is more an implementation detail of how extension roaming could work. Moving to @sandy081 but feel free to close off as things have changed a lot since 2016

[sandy081]

We are now having a manifest of installed extensions in profiles.