Ability to use and override default profile settings in a custom profile

[sandy081]

Ability to use and override default profile settings in a custom profile

NOTE: Please mention your use case / scenario (NOT how you want to use) for this requirement. Also try if available Profiles features including #156144 are helping

[tanishqmanuja]

Use case: #156144 (comment)

[tanishqmanuja]

I have recently updated my approach towards maintaining my vscode settings.
Purpose of sharing it here is:

• Feedback for improving/ Discussing any alternative method
• Reporting the pain points in this approach to vscode devs

EDIT: In C/C++ extensions block, I meant C/C++ specific extensions instead of JS.
LINK: tldraw

Pain Points

These are marked with red arrow

• Have to copy all defaults manually
• No way of enabling extensions for workspace via code/json. Code can be copy-pasted/automated but not GUI actions.

[cdce8p]

No way of enabling extensions for workspace via code/json. Code can be copy-pasted/automated but not GUI actions.

Would love to do that as well. I frequently need to enable the same extensions for new (temporary) workspaces.
In theory it would be possible to edit the state.vscdb database files and overwrite extensionsIdentifiers/enabled but that's something which should be simpler to accomplish.

[jcrben]

The use case I envision is for team sharing of settings. I want to create base default settings for all my team members which they can easily override if they feel so inclined. Then I want them to be able to use a profile as well on top of this foundation. If I could do that via something like https://learn.microsoft.com/en-us/windows/terminal/json-fragment-extensions that could be nice altho maybe that's overcomplicating it - I just want a single base.

[thernstig]

I believe the solution should be akin ESLint extends, or Ruff extends, or any other similar tool.

The current way of using workbench.settings.applyToAllProfiles is not sufficient to capture everything. Here is an example of this shortcoming. Imagine I have this in the applications setting (Default Profile):

{
  "workbench.settings.applyToAllProfiles": [
    "editor.codeActionsOnSave"
  ],
  "editor.codeActionsOnSave": {
    "source.organizeImports": "never"
  }
}

Imagine I have this in a Web Profile setting.json:

{
  "editor.codeActionsOnSave": {
    "source.organizeImports": "always",
    "source.fixAll.eslint": "always",
    "source.fixAll.markdownlint": "always",
    "source.fixAll.stylelint": "always"
  }
}

There is no way for me to override the individual items in the object.

Setting values can be of various types. Such merging is well handled by normal settings.json merging between user, remote, workspace settings etc, see https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence.

Here is an idea of a better solution:

Default Profile

  "editor.codeActionsOnSave": {
    "source.organizeImports": "never"
  }
}

Web Profile

{
  "extends": ["Default Profile"],
  "editor.codeActionsOnSave": {
    "source.organizeImports": "always",
    "source.fixAll.eslint": "always",
    "source.fixAll.markdownlint": "always",
    "source.fixAll.stylelint": "always"
  }
}

This has several benefits:

• You can nest multiple extends where precedence is from right-to-left (i.e. last item has highest precedence). This enables a hierarchy of profiles e.g. "default -> web -> web with Golang backend" OR "default -> web -> web with Python backend".
• You easily see in the lower-layer profiles what they extend, instead of having to go to the Default Profile to see what gets into lower profiles.
• https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence can be respected with type merging, meaning objects merge better.

If doing this, it would be great if a rename of a profile name also updates extends: ["Default Profile"], so the names sync, which could easily be missed otherwise.

[thernstig]

Thinking more about #188612 (comment), it might even be more beneficial to create this extends functionality directly built into the Profiles. Rationale being that then also Extensions, Keyboard Shortcuts etc. could be merged in a nicer way.

So let's say you have Default -> Python Development -> Python Development Ruff Default -> Python Development -> Python Development Flake8, you could share the Python Development and get the Python extension in both, but different linter extensions Ruff vs. Flake8. Just as a dumb example. So not only settings would be merged, but also the others. So Extensions would be a be a union of the all extended Profiles.

[sharpchen]

I wonder with current solution, when create new profile from default with settings, does it simply copy settings or references them from default?

[brettcannon]

I wonder with current solution, when create new profile from default with settings, does it simply copy settings or references them from default?

I believe it references them.

[soimon]

I wholeheartedly agree with Tobias Hernstig (@thernstig) on #188612 (comment): this is the way I would expect the system to work, given my experience with various configuration files that follow the same logic.

I would like to propose the idea of multiple inheritance (with the settings being merged in order, i.e., the latter one overwriting the earlier one). This would allow you to truly separate different contexts and environments.

You could have profiles for each language and context, stacking them just like you stack your tech stack:

{
  extends: ["Svelte Profile", "Python Profile"]
  // Svelte frontend with Python backend specific settings here
}

graph TD;
    golang(Golang)
    svelte(Svelte)
    python(Python)
    edu("Presentation (larger fonts, etc.)")
    svelte & golang-->c1[Svelte frontend with Golang backend]
    svelte & python-->c2[Svelte frontend with Python backend]

Loading

In this approach, a profile becomes an expression of extensions and settings you'd like to have available when working in a specific context or using a particular technology. It's like knowing you're heading to the gym and doing groceries afterward: you simply grab your sports bag and wallet, and the union of these allows you to do all your activities without having to think too much about what's inside either of them.

To avoid having to set up a jungle of profile combinations, it makes sense to specify this union in your workspace file, as the combinationary aspect is typically specific to the workspace.

While this idea might extend beyond the initial scope of what this system was intended for, I think it offers the most flexible and (for a lot of developers) familiar approach.

[thernstig]

soimon yes, multiple inheritance is captured in #188612 (comment) since the example uses an array for extending.

However, I think I make a fair point in #188612 (comment) that this should possibly not go into the settings.json but rather Profiles directly.

[tanishqmanuja]

Since, this feature is still not supported. I am using the extension enable/disable method, can anyone tell me how to suppress these warning when the extensions are disabled.

[jmevel]

Tanishq Manuja (@tanishqmanuja) when you switch to a profile you have to reopen the settings file because VS Code will keep the previous settings file open.

I always add a comment at the top of all my settings file to quickly know which one I'm currently modifying.
For example I have // DEFAULT settings for the default profile and // RUST profile settings for my Rust one.

The default' settings file is located under (for Windows) under %APPDATA%\Roaming\Code\User but any other profile's settings file will be under %APPDATA%\Roaming\Code\User\profiles\profile_ID

Your setting won't be recognized if you don't have this specific extension enabled in the current profile you selected.