Add ability to extend from other settings files

[maxdeviant]

Inspired by TSLint's ability to extend configuration files, it would be nice if .vscode/settings.json could behave the same way.

So if I have some global settings set up:

~/example-repo/.vscode/my-company-settings.json:

{
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "editor.formatOnSave": false
}

I can use them in another file, without having to duplicate the settings:

~/example-repo/my-project/.vscode/settings.json:

{
  "extends": "../../.vscode/my-company-settings.json",
  "editor.formatOnSave": true,
  "editor.fontLigatures": true
}

And the computed settings for ~/example-repo/my-project/.vscode/settings.json would be:

{
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "editor.formatOnSave": true,
  "editor.fontLigatures": true
}

Scenario:

Multi-root workspace doesn't solve this for our use case. We have a bunch of npm modules each in their own git repository. We have a package which contains our shared tsconfig.json and tslint.json settings that all the other packages include with extends. We don't use a multi-root workspace since the idea is that people can clone the specific package(s) they need to work on. Every repository contains the exact same .vscode directory which is essentially copy&pasted all over the place. Maintaining the .vscode settings for the projects is "not pretty" compared to the tsconfig.json and tslint.json which only require the settings package to be updated with for example yarn upgrade.

[mweststrate]

+1: Our mono repo consists of six projects which have largely, but not entirely the same settings.json files

[maxdeviant]

@mweststrate A monorepo is exactly why we desire this as well 😄

[andreineculau]

@sandy081 am I correct in saying that you're advocating that large groups that share common settings should create their own extension? #15162 (comment)

If you know of such an extension that would be a great reference. Thanks!

LATER EDIT: for instance, I can only think of https://github.com/editorconfig/editorconfig-vscode to be on the same line as what we are trying to achieve here, and that one applies configuration to each editor (each tab). Overall, if this is accurate, the effort (boilerplating) seems quite high for a common goal of settings reuse.

[sandy081]

@andreineculau No, I did not mean that. I was mentioning about settings contributed by extensions.

[mmkal]

@bpasero @jrieken any update on this? Would the team be open to PRs?

IMO the lack of this feature is the reason that questions like should I commit the .vscode folder to source control? are controversial/asked at all. This isn't just useful for monorepos - it could allow having settings specific to a project and user.

Say you have team settings checked in to .vscode/settings.json, but you want to set something to some specific value, only for a single project. Currently you'd have to make that change in the team .vscode/settings.json file, which sucks because you'd the either have to check it in to source control for the whole team, or add the file to .git/info/exclude (in which case every time you do need to update the file in source control, you have to undo the exclusion, remove your personal settings, apply the team changes, check-in, re-apply your personal settings and redo the exclusion).

If settings/tasks/launch.json supported extends, you could have a .vscode/settings.team.json with the team settings, then .vscode/settings.json could be:

{
    "extends": ["./settings.team.json", "./settings.user.json"]
}

where .vscode/settings.user.json is in .gitignore. launch.json and tasks.json could work in exactly the same way (I guess this feature would probably need to be implemented so it can handle the ./settings.user.json not existing).

[bpasero]

@mmkal with multi root workspaces we have a new way of defining settings without having to check them in. Currently only available in insiders (https://code.visualstudio.com/insiders/) you can save a workspace with any number of folders (File > Save Workspace As) and this will create a *.code-workspace file where you can add workspace settings into. All settings are scoped to this workspace and they will not get checked in to SCM.

The only downside of this approach is that settings defined within the folders will still override the workspace settings. But I think that is fair because a setting that is checked into SCM should always have higher importance imho.

[amp343]

@bpasero that feature doesn't really address the use case that @mmkal described though, where a base settings.json (presumably tracked) would be extendable/overridable by a settings.user.json (presumably untracked).

The use case for this is that a team may want to track and distribute shared settings for a folder (using the existing settings.json), but give individual users the flexibility to opt out of those settings (via settings.user.json).

The pattern I'm thinking of is similar to the one used in docker-compose, (https://docs.docker.com/compose/extends/) where you might have a tracked docker-compose.yml (shared base/prod config), and an untracked docker-compose.override.yml (local development overrides) that automatically extends from the base config.

I think something like this could be a powerful feature, especially for adoption across larger teams.

(edit - Oversimplistic example: https://github.com/amp343/vscode/pull/1/files)

[mmkal]

@bpasero @amp343 is right, multi-root workspaces are great, but they only really solve problems to do with having related projects, not so much version control/different developers working on a repo - or tasks/launch.json.

One approach that would solve for almost all use cases would be to allow tasks.js, launch.js and settings.js, as well as .json files in the .vscode folder. That would allow for this, and many other features too. Similar to how jest allows defining a jest.config.js file where you just put module.exports = { ... }.

That way if a team needed to have default settings, overridable by individual developers locally they could define whatever custom extension logic they liked insettings.js:

const { existsSync } = require('fs')
const localPath = __dirname + '/settings.local.js'
const userOverrides = existsSync(localPath) ? require(localPath) : {}
module.exports = {
  // team settings
   'tslint.enable': true,
   ‎...userOverrides,
}

If you wanted to get fancy, you could use lodash.defaultsDeep. For very complex or widely-used configs, people could even publish their configs to npm and they could be intalled as npm dev dependencies, and used by others with very little effort.

Again, would the team be happy to accept PRs for something like this? It seems like multiple people would be willing to help, (including me).

[ilius]

I also want to sync my vscode config directory (including settings.json, but excluding some specific paths like Cache*) between home and work (using git), but there are few things I don't want to sync (like window.zoomLevel which i change depending on display size). If we could import / extend another json file in settings.json, that would solve my problem.

[zpdDG4gta8XKpMCd]

at very least you can keep looking for settings in parent folders, can't you?

[sandy081]

@maxdeviant What is your use case here to want the settings to be extended? Is it to have non-sharable workspace settings or something different.

@mmkal @amp343 To have non-sharable workspace settings did you try following?

• Open empty window
• Use command Add folder to Workspace and add the folder in which you want to have non-sharable settings
• Open Workspace settings and have your personalised settings for that workspace

In this way you do not need to change the team settings in the folder which are shared.

[maxdeviant]

@sandy081 Wow, it's been a while since I opened this issue, I'll see if I can remember 😅

The original use case was that I wanted to be able to share common settings across multiple VS Code projects. So I wanted the ability to have a base .vscode/settings.json somewhere in our repo with common options (e.g., indent size) and then point all the other settings files to that base file and be able to inherit the base settings.

We're using multi-root workspaces now, so I don't really think this is an issue for us anymore.

[RobertLbebber]

Unless I'm not getting something, which is likely the case. There is a big distinction between workspace and setting.json.
Why would I want to commit my color theming to a repo in the .workspace, yet I can't set that in the settings.json. That flies in the face of what should be committed versus what shouldn't be. Another one is having the side bar on the left rather then right, this would have to be commited in the workspace file rather than the personal settings file

[nolimitdev]

@Andonvr

Would love to have this. I need to split my workspace settings into two: One file that I can commit and share with coworkers, and one for personal customization.

We exactly do this using this way: #15909 (comment) ...

We partially solved it by sharing team settings in commited file .vscode/project.code-workspace and if developer need some project-specific settings just for himself he can use gitignored .vscode/settings.json which has precedence. I think that better fallback does not exist now.

Please try it and give feedback!

This is not ideal solution as some use-cases will not work. It is just fallback for missing official feature of extending settings. For example if I have { "settings": { "window.title": "Foo" } } in ./vscode/project.code-workspace and then when I try override it to custom developer value using { "window.title": "Bar" } in ./vscode/setting.json it does not work: This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly.. But for example overriding stylelint setting works this way so we are happy for that partially working fallback. Everybody should test its use-case if it is possible override what he need.

[nbbaier]

I would also love this feature, adding my vote.

[nevercast]

Even without the "extends" functionality, we would love to have settings.user.json. We have team configuration in settings.json, which is tracked in Git. This helps our team have a common configuration for extensions, linting etc.

But some of our team members also want to make stylistic choices in the workspace, such as workbench.colorCustomizations. Particularly on a per-project basis as it helps them context switch when moving between projects (workspaces).

Currently we can't offer such changes without:

1. Asking them to apply that setting at a user level and apply their customisations to the entire VSCode experience (which gets overridden by any team settings in .vscode/settings.json anyway.) This still doesn't give them per workspace overrides.

2. Making settings.json assumed unchanged in Git, then the user can apply their changes on top of the team settings. Which is more technical than we would like and not something we want our teams to be doing. Ideally.

It seems this issue has been raised in the past, e.g. #38902 which was closed for not being on the roadmap. That was almost 6 years ago. This issue itself is 7 years old.

It would be fantastic to get some feedback from the VSCode team on if they are willing to put this on their roadmap. Further, if they are willing to accept PRs to support either the settings.user.json functionality, or the "extends" functionality.

Edit: I found #37519 which is also related, and we tried the code-workspace approach but as mentioned above by nolimitdev's comment, code-workspace will disable settings.json entirely for some keys. This makes the precedence rules confusing and also not viable for our needs.

[starball5]

@nevercast settings.user.json is also a good idea. That's pretty much what CMake does with CMakeUserPresets.json and CMakePresets.json. See https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html.

[birgersp]

@nevercast

... support either the settings.user.json functionality, or the "extends" functionality.

I'm curious, why would you possibly want settings.user.json feature, over "extends" functionality? The latter already covers the need for the former, and would be so much more flexible.

Let's focus. We need the ability to extend from other settings files, not some quasi-solution that would help in just some of the cases where a "extends" feature is desired.

Case in point (taken from top comments):

+1: Our mono repo consists of six projects which have largely, but not entirely the same settings.json files

I'll also add that I think all config files in VSCode should be able to "extend" from other config files. Not just settings.json but tasks.json, launch.json, workspace files (project.code-workspace), even keybindings.json. Currently, managing multiple projects in a monorepo by copy-pasting the settings between the config files is a pain in the behind.

Chop, chop 🔥

[nevercast]

@birgersp Because either option satisfies my requirements.

Undoubtedly the extends feature is more versatile.

[nsgundy]

For us, we have both workflow requirements reiterated by @birgersp and @nevercast.

1. A mono-repo with multiple projects that due to their similarity share a lot of their settings. For example:
   • recommending the same extensions (we currently do that mostly in .vscode-workspace files)
   • common settings either via settings.json or .vscode-workspace for the extensions and the languages used in those projects
   • common tasks via tasks.json, like cleaning, building, running unit-tests that only differ slightly in their name to include the project label, so that when you open a workspace at the root level, its easier to tell these apart
   • common launch configurations via launch.json, often referencing pre-launch tasks from tasks.json
2. Users requiring to set some specific variables in settings.json that are used by common tasks and launch configurations, but are unique to their setup, like targetIp for the address of the system used for debugging. All too often these changes then get accidentally committed.

In short, for us, a generic "extends" feature that spans all configuration .json files would be the most useful. It would make maintaining / setting up new projects a lot easier.

By the way @nevercast, we have had the same issue around workspace colors and eventually settled on pre-defining those in the committed .vscode-workspace files. This has the benefit that our developers feel right at home when pair-programming. Obviously not good for those who prefer to go their own way.

[starball5]

FYI people, as a workaround to some of these use cases, you could consider using profiles. Profiles can have settings.json, tasks.json, etc. and then you can either individually select the profile for each workspace you want it to apply to, and VS Code will remember your profile selection for that workspace, or you have open VS Code via CLI with --profile <your profile name>.

[ackvf]

@starball5

@ackvf read literally the comment directly above yours :|

OMG! thanks! Though, funnily enough, or sadly, we have both of the files checked in the repository 🤦‍♂️🤦‍♂️, but this is a great direction anyway, thanks for the hint. I will propose consolidating them into one and then ignoring one of them to allow this.

@nolimitdev

We partially solved it by sharing team settings in commited file .vscode/project.code-workspace and if developer need some project-specific settings just for himself he can use gitignored .vscode/settings.json which has precedence. I think that better fallback does not exist now.

I wish the precedence was the other way round though.
Shared .vscode/settings.json config checked into repository and then having as much project.code-workspace as necessary. Each can have slight variation depending on the task at hand.

For example: some people might prefer having another repo or a workspace folder included in IDE, some not. If the project file is checked in the repository, it removes this flexibility from you.

[recursivenomad]

Chiming in to voice that this would be great in my use-case for referencing an external launch.json file provided by an SDK, without having to manually copy the file into my settings.json or .vscode directory every time there's an update to the SDK.

[adrian-85]

Building on this topic, is it possible to have a global settings.json read from a JAR file? We are using a framework that has a unique DSL, preventing us from leveraging common linting tools. At least this way we could add some basic rules such as tab length, rule lines, etc as part of the JAR.

[d1onys1us]

wow im already back here again. can we plz implement 🙏

[divmgl]

This is becoming much more relevant now with monorepos.

[testfailed]

For a minimal workaround, I'm disabling all project-specific plugins, enabling ones related to each project as workspace plugin and add those into Workspace Settings' recommended plugins. Likewise, I'm only defining common or fallback settings in User Settings and project-specific settings in Workspace Settings.

I've been hoping to switch vscode envs with each corresponding project-specific profile (Node.js, Python, Java, etc.), but I guess that's all I can do for a workaround.

[bytebeast]

did not read the whole thread, so apologies. i did however have an opinion on the name of the key...

{
    "include.settings": ["./settings.team.json", "./settings.user.json"]
}

wow, just realized this was an old ask 😔
please 🙏 implement.

[dir]

I'd love this just for cleanliness. Sometimes my settings.json files can get absolutely massive if they have large arrays, etc. Would be nice to have a linting.json, formatting.json, editor.json, etc, and then merge them all

[adam-azarchs]

Minor note, for the settings.user.json use case, which I think is what a lot of people are interested in, it would be most helpful if vscode would silently ignore it if the file was missing, since one would usually want to put that file in .gitignore. You probably wouldn't want it to silently ignore missing files in other cases, as that could be confusing to debug, so it might be helpful to permit something like

{
    "extends": [
        "settings.team.json",
        {
            "file": "settings.user.json",
            "ignore_missing": true
        }
    ]
}

[DeanAyalon]

Just to note, settings shouldn't necessarily be the only file extended, as extensions.json and others should probably also have this functionality

Within a monorepo, multiple projects have different recommended extensions, and opening the entire monorepo should recommend all of them

[RobertAKARobin]

Is there anything we as a community can do to help move this from the Backlog to e.g. On Deck?

[ryanjafari]

A very helpful comment, thanks @RobertAKARobin I'm guessing this portion of code is closed source?

[Kytech]

A very helpful comment, thanks @RobertAKARobin I'm guessing this portion of code is closed source?

I'm pretty sure that the loading of settings is part of the core open-source editor as most VSCode forks have the exact same settings loading functionality. Most closed-source components of VSCode seem to be distributed as extensions (bundled in the standard VSCode distribution or otherwise), or have closed-source web backend components.

Is there anything we as a community can do to help move this from the Backlog to e.g. On Deck?

I think the most helpful thing we could do as a community is try to come up with a proposed implementation for settings file extension, then draft a PR for the feature. Seems like there's been a number of different ideas for how this feature should be implemented, but if there's an implementation that those interested could agree upon, it would probably be relatively straightforward to implement. Having a coherent design for the feature would also make it easier for several people to contribute to the PR if one single person can't find the time to work on this. I've wanted to sit down and take a look at what would be required to implement this feature in a PR, but there's just too many other things that take priority over this for me these days.

[paskaran]

It's unclear why this issue still hasn't been addressed by VSCode, even after almost 8 years. I was searching for a solution, only to discover that none currently exists. quite sad!

[viliusan]

Bumping this issue as we are also looking for a way to extend a base settings.json file in a monorepo context.
It sucks to have duplicate settings for every application in a repository.

[kasvtv]

I'd love to provide a checked-in base settings file with simple defaults for the workspace (e.g., lintint and autoformatting), that other devs on my team can then extend to fit their personal preference using a gitignored settings file.