Explore user profiles

[miguelsolorio]

Overview

This issue aims to explore what adding "profiles" could look like in the product. These profiles can be used in education, presentations, or can even be language specific. The explorations should cover being able to setup and switch between profiles. Ideally these profiles should be synced with Settings Sync (if used) so you can use those profiles anywhere.

One idea for settings is to introduce a new settings object like:

{
    "profiles": {
        "demos": {
            "files.autoSave": "onFocusChange",
            "editor.fontSize": 18,
            "editor.tabSize": 2,
            "editor.fontWeight": "600",
            "screencastMode.enabled": true,
        }
    },

    "editor.fontFamily": "Cascadia Code",
    "editor.renderWhitespace": "all",
}

The "Demos" profile inherits the current settings a user has and adds additional settings on top of the current ones. Also, when profiles are enabled we will create a "Default" profile where the user can switch back to their default mode.

Related issues

• Screencast Mode only settings #105226
• Sync mutliple settings profiles #92393
• Multiple environment profiles (either per-session or per-window) #57548
• User profile #53453
• Enable/disable extensions from config file #40239
• Local Workspace settings #40233
• Support "perspectives" like approach in VSCode #95182

[miguelsolorio]

Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

[miguelsolorio]

Concept B

This concepts attempts to re-use the accounts menu in the activity bar and also creates a default profile and reduces the effort involved with creating/switching accounts.

[carlocardella]

One idea for settings is to introduce a new settings object like:

{
    "profiles": {
        "demos": {
            "files.autoSave": "onFocusChange",
            "editor.fontSize": 18,
            "editor.tabSize": 2,
            "editor.fontWeight": "600",
            "screencastMode.enabled": true,
        }
    },

    "editor.fontFamily": "Cascadia Code",
    "editor.renderWhitespace": "all",
}

The "Demos" profile inherits the current settings a user has and adds additional settings on top of the current ones. Also, when profiles are enabled we will create a "Default" profile where the user can switch back to their default mode.

So with this approach if I update a setting in the default profile (say editor.fontFamily) but I want the Demos profile to use the default font instead, it should be overridden with its default value here?

That would also mean that every change made in the default profile is automatically inherited by all other profiles? If the change was intended only for the default profile, all other profiles should be modified to revert that change?

I realize it is probably unlikely someone will have a high number of profiles (but who knows, really?); one way to avoid the revert problem above would be to not inherit from the default profile, maybe only use it as a starting point when a new profile is first created. Of course that also means if I change a setting in the default profile that I do want inherited, I'm out of luck... Maybe this inherit from default profile could be a setting as well?

[jjspace]

Maybe this inherit from default profile could be a setting as well

What if it was set up in a similar way to how .eslintrc can "extend" other configurations?

For example, when you create a new profile it starts with an "extends-profile": "default" setting which would mean it always inherits from the default, even if default changes. If you no longer want this behavior just remove this extends setting and this profile would go back to App defaults for everything that's not set for that profile?

This would also allow profiles to extend each other (and maybe even allow people to share them!). To go with OPs example, maybe I have a teaching profile with bigger font/zoom and some parts hidden. But now I start teaching another class in a different language and I want a different set of extensions or maybe a different theme that's better for this language. I could just create a new profile that extends my base teaching profile with just the new settings.

I guess this would still leave the question of "if I change a setting of the 'child' profile, which level of the config do I want it on, this one or the parent?" Maybe it's still best to have no inheritance at all and all new profiles should start with App defaults or duplicate the default at creation.

[jjspace]

Also not directly related to current conversation but the term "Profiles" threw me off at first. I was expecting something along the lines of User profiles like multiple Chrome accounts. Not different configuration sets. I think profiles works but it may be worth thinking of alternatives?

[miguelsolorio]

Yea I did originally play around with the "inheritance" concept, mostly focused on disabling it in a certain profile. The idea of mixing profile sounds interesting but would love to see a use case for it first because it could add some unnecessary complications, like you just described.

In terms of the term "Profiles", this one is tricky because we do also have user accounts where you login for certain extensions (like GitHub or Azure), so we want to make sure those are separated and not mixed. But thanks for this feedback, we'll gauge to see if we get similar feedback.

[yume-chan]

I prefer concept B. Looking together with #115641, maybe there is no such strong need for the account manager. I personally never touched it after setting up all my accounts.

However, from these early concepts, I did get how it will resolve all related issues.

• Can I use different profiles for different Code instance? Will it switch profile automatically when opening a workspace or enter/exit screencast mode?
• I care more about #40233, what's the priority of profile settings? Will it be like user settings < profile user settings < workspace settings < workspace profile settings?

[gjsjohnmurray]

Another related issue is #95182, which proposes the term "perspectives".

[LucaGabi]

Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

This looks very good and easy to use also. B is hard to navigate in my opinion.

[NowanIlfideme]

Hi, would this "user profile" concept work for multiple accounts in vscode itself? For example, I use vscode for personal projects (personal email & GitHub account, this one), but also for work (my employer's msft-based email & work GitHub account), potentially also integrating with a customer's system (e.g. their Microsoft account). However, I want my settings to sync via my personal email (for example), or at least to start both from the same config.

[RobJacobson]

Great ideas! I'm looking for a simple tool that allows me to switch profiles/extensions between my HTML/CSS/JS stack, my Python stack, and my Ruby stack. There's no need for one set of extensions to coexist with the other sets of extensions, and it's really tedious to enable/disable extensions by hand.

For example, when coding Ruby, I don't need ESLint to be enabled as an extension. I would prefer it ESLint just "didn't exist" in that VS Code workspace (not merely be disabled).

There is already an extension that does much of this, Profile Switcher. Unfortunately, it's still in version 0.3.3 and has been since 2019. It appears to be abandonware. It might be buggy, or I might be buggy (PEBMAC), but it seems to have "forgotten" a large number of my favorite extensions. Now I need to do a "hard reset" of VS Code and reinstall them.

https://www.aaron-powell.com/posts/2019-06-28-vscode-extension-for-managing-profiles/

There are articles/blog posts at the links below about how to switch user profiles from the command line. However, this also seems rather tedious. https://dev.to/sulmanweb/vs-code-pro-tip-code-profiles-multi-environment-development-hg2 https://www.reddit.com/r/vscode/comments/c2h4a7/different_profiles/ https://dev.to/jsjoeio/how-to-create-code-profiles-in-vscode-3ofo https://www.freecodecamp.org/news/how-to-create-code-profiles-in-vscode/

Could the VS Code team please consider making this an available option? It could be as simple as taking the existing Profile Switcher code (MIT licensed) and cleaning it up.

[RobJacobson]

There's also another extension, "User Profiles," that seems to have been released just a few days ago. https://github.com/cyberbiont/vscode-profiles

[U-C-S]

Any progress on this one?

[Chaphasilor]

I simply wanted to add another "User Story" for this feature, as well as a more detailed implementation strategy

Similar to what @RobJacobson said, I'm looking for a way to first and foremost configure profile-specific extension sets.
My use-case:

Working with "writing" tools like LaTeX or markdown is often an involved process, with numerous heavy-weight extensions being required. However, 95% of the time I'm not writing and therefore not using these extensions. Disabling and re-enabling these extensions manually would be a solution, but a very tedious, lengthy and error-prone one.
Switching profiles, including active extensions and settings (e.g. Word Wrap Column in this case), on a per-workspace basis, would be the perfect solution.
Using workspace-specific settings would also be possible, but in this case I'd need to manually "duplicate" these settings if I start a new writing project that is unrelated to the others, and I dislike having multiple folders added to a single workspace :)

What I would suggest is giving us the profile functionality, tied to workspaces, so that we can select a specific profile for each workspace. A "default" profile could be used well, by default, and changing the default profile would cause all workspaces, which use the default profile, to change as well.

This should cover most use cases with a very simple concept that is completely compatible with Concept A (status bar items, like the current git branch or Workspace Trust, are also tied to the workspace).

[evandcombs]

For the name of this feature may I suggest 'Environments'.

[gjsjohnmurray]

Linking to https://code.visualstudio.com/updates/v1_67#_settings-profile

[hoa00]

I like to contribute my idea. My idea was to have this as part of a project. Maybe part of extensions.json in .vscode directory.

extensions.json inside my node.js based project

I believe this is simpler from a user's point of view

This idea is awesome

[Sylk]

Would love to see this as a feature, it's difficult to have so many different stacks in a single editor. The intellisense starts playing goofy if I can't sandbox it down.

[gjsjohnmurray]

After switching to a different profile it can take a few seconds before all the changes have been applied. It would be good to have a progress indicator. Perhaps a spinner in the status bar item. Or a progress notification, which could perhaps also inform us a seach part of the switchover is being performed.

[sandy081]

Hi all, the latest Insider release has support for settings profiles. It would be great if you can try it out and provide us feedback through issues or comments in this issue. You can enable this feature in insiders using the setting workbench.experimental.settingsProfiles.enabled.

[iRoachie]

Hey folks 👋🏾 now stumbling upon this issue.

Does this support setting different github accounts per profile?

My use case is that my personal/oss github account is different from my work account. Currently getting around this by using VS Code for work and VS Code Insiders for personal/oss.

Wondering if this is tackled in this effort.

[sandy081]

I do not think so, Accounts are handled across profiles.

CC @TylerLeonhardt

[TylerLeonhardt]

@iRoachie you'll want to follow along with this issue: https://github.com/microsoft/vscode/issues/127967#issuecomment-1111420554

We'll need that before we can do a "different github accounts per profile"

[Kevin-Delnoije]

@sandy081 I really like the new profiles it basically solves al my gripes with toggling extensions i could not find a way however to choose profiles from the command line e.g. code --profile profile.code-profile so that i can alias different profiles in terminal. Another thing i would love to see is a global config for settings like theme and keybindings which are mostly independent of different projects. maybe giving multiple profiles and merging could be a solution? code --profile global.code-profile project.code-profile

[xiaoxi-david]

It would be very interesting if VS Code came with preconfigured profile settings including official and most popular extensions for the most popular programming languages.

[sandy081]

@Kevin-Delnoije Thanks for trying out and providing feedback.

i could not find a way however to choose profiles from the command line e.g. code --profile profile.code-profile so that i can alias different profiles in termina

CLI support for profiles is in progress.

Another thing i would love to see is a global config for settings like theme and keybindings which are mostly independent of different projects. maybe giving multiple profiles and merging could be a solution? code --profile global.code-profile project.code-profile

I see your point and heirarchies in profiles will make them complicated to use and understand. So we will collect more feedback here to understand more about this.

[femto-code]

I am interested in seeing the user profiles evolving. From a developers point: how is switching between different profiles accomplished in terms of extensions? Assuming you have different sets of extensions there seem to be two options for me:

1. Are extensions uninstalled, so deleted from disk? This would mean new download on next switch.
2. Or maybe cached? Maybe just moved away from extensions directory? This way an extensions would be moved in place if selected in user profile.

[femto-code]

I agree with @Kevin-Delnoije in the matter of a few additions necessary in order to make the settings profiles adoptable to one's own use case:

1. Allow binding a settings profile to a workspace/directory (preferably via workspace/folder settings.json, maybe include the .code-profile there)
2. Provide a way of having a global configuration i.e. extensions or settings/keybindings that would be independent from profiles (the application-level settings also go here).

[sandy081]

Extensions are not uninstalled or installed (downloaded) during profile switching. It is just loading the set of extensions listed from the profile that is active.

Allow binding a settings profile to a workspace/directory (preferably via workspace/folder settings.json, maybe include the .code-profile there)

Yes, Settings profile are associated to a workspace. Please try out the Settings Profiles which are available in our insiders and give us feedback.

Provide a way of having a global configuration i.e. extensions or settings/keybindings that would be independent from profiles (the application-level settings also go here).

Please help me in understanding your use case here and also how you want to see this in VS Code with existing Settings Profiles feature.

[femto-code]

@sandy081 Use case would be simple: I have multiple workspaces and don't want to have individual profile settings that I have to maintain separately. I think it would be great to give the opportunity so select what to include in the .code-profile. E.g. if settings are not included then the global settings file in user data dir is used. Another option would be to have an auto merge option. At least global settings would be a must-have for me.

[scnwwu]

Say I've created multiple profiles. Now I found a new theme (or new extension) which is awesome and I'd like to use it globally. In current Insiders version, I have to manually apply in each profile right? One idea would be adding another tab say "Profile" in the Settings page beside User and Workspace. Change the settings in the User tab will affect all profiles for the user. And there can be "Enable (Profile)" beside "Enable (Workspace)" in the extension menu. Another idea would be to have a "Base" profile. The extensions enabled in the Base profile work across all profiles. Any settings that's not a default value in Base profile work across all profiles, something like that. I think it's a common case that user want some settings applied globally and some per profile.

[alefragnani]

Extensions are not uninstalled or installed (downloaded) during profile switching. It is just loading the set of extensions listed from the profile that is active.

Is there any chance to expose this loading set of extensions feature/API to vscode.openFolder command?

Today, this command only supports an Uri describing the folder/workspace path to be opened. It would be interesting to allow adding the set of extensions to be used as well, or at least the profile, just like you are exposing in #151301.

Thank you

[sandy081]

@femto-code @scnwwu Thanks for the feedback. Extracted the discussion into a separate issue - https://github.com/microsoft/vscode/issues/156144. Please continue discussion there.

[sandy081]

@alefragnani Please file a separate issue for your requirement

[alefragnani]

Filed #156173 as requested. Thank you!

[gusbemacbe]

@alefragnani and @sandy081

I want to create a new current profile or export a profile with workspace settings instead of user settings. Why? Because the user settings are already global in all projects. I would rather not include Java settings in the global user profiles, but in a Java workspace settings.

I already tried to explain you in te past regarding #90649, but my autism limits my communication.

[gusbemacbe]

I do not recommend Microsoft's VSCode's native Settings Profiles!

I used to enabled more or less than 120 extensions for basic Markdown projects on a workspace. I exported the settings profile, then I imported into… It got a disaster! It enabled almost all the extensions for a basic Markdown profile!

I really miss @aaronpowell's depreciated extension VSCode Profile Switcher that was totally functional.

[gusbemacbe]

I made another test, importing a basic Kotlin profile. It really enabled all extensions. Not only it, when you import the settings profile, …:

• it will install all the extensions even if they are already installed in the ~/.vscode-insiders/extensions!
• you'll be asked to change more than seven languages, to insert CodeTime and WakaTime tokens, etc.

Totally disastrous.

[sandy081]

@gusbemacbe Thanks for testing the feature and providing the feedback. import/export functionality of Settings Profiles does not support workspace specific state like workspace extension enablement. This feature is still under work in progress and behind experimental flag. Can you please open a separate issue and explain your scenario / use case so that we can cover it in this new feature?

[rockboynton]

suggested setting for enabling this feature is not recognized for me

[carlocardella]

@rockboynton this feature is still in preview in Insiders only, please check the VSCode version you are using

[rockboynton]

@rockboynton this feature is still in preview in Insiders only, please check the VSCode version you are using

got it, thanks!

it's a bit confusing because some of the experimental features just need to be enabled and some need insiders, and that's not always specified

[markovicdenis]

Would it be possible to switch profiles automatically based on system theme mode (dark/light)? Someone probably needs to make an extension for that, since it would be out of the scope for this feature?

[sandy081]

Would it be possible to switch profiles automatically based on system theme mode (dark/light)? Someone probably needs to make an extension for that, since it would be out of the scope for this feature?

@markovicdenis Thanks for the idea. But, there are no plans to support that in core.

[kamenminkov]

The setting is still not recognised in the latest Insiders 1.71 version as of today; was it disabled at some point?

[carlocardella]

Interesting, it may have been hidden by mistake in a recent Insiders release, I still see the menu commands (maybe because I had enabled the setting before) but it is gone from the configuration:

[carlocardella]

@kamenminkov It looks like in Insiders the setting is no longer needed? This is a brand new setup on a brand new VM (to avoid settings cached somewhere) and Settings Profiles is available out of the box:

[sandy081]

We enabled this feature by default in insiders and from next release this is also enabled in stable but behind the flag.

[kamenminkov]

Thanks for the explanations - it makes sense now.

Started playing around with those - and what comes to mind immediately is that it will be super useful to have some inheritance/overriding pattern (e.g. in a similar fashion to what we now have - how a workspace setting can override a user setting). The way I see it now is that you have to maintain two sets of settings with no way of providing a common base to them to inherit from - or perhaps I'm missing something else? No doubt the current state would come in handy for people who need to maintain different settings and extensions for different tech stacks, but IMO there needs to be a way to have a common base too; if I'm jumping between technologies, I personally would like to preserve for example font and colour settings, some of my extensions, most of my keybindings and things like that - and I believe it would be the same for other people.

[daviddossett]

there needs to be a way to have a common base too; if I'm jumping between technologies, I personally would like to preserve for example font and colour settings, some of my extensions, most of my keybindings and things like that

We're certainly thinking about this. Stay tuned 👍