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.

[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.

[charlietran]

This extension appears to add this capability, has anyone here tried? https://marketplace.visualstudio.com/items?itemName=KalimahApps.tabaqa

[ArseniyKruglov]

@charlietran, Tabaqa is better than nothing. Unfortunately, it can't extend multiple files.

[muzafferkadir]

Managing Multiple Projects in VS Code with Git Integration

When working with multiple projects in a single repository, especially when the Git repo is in the parent folder, here's how to set it up in VS Code:

1. Create a workspace file (your-project.code-workspace) in the parent folder containing the .git directory.

2. Structure your workspace file like this:

   {
     "folders": [
       {
         "path": ".",
         "name": "Root (Git Repository)"
       },
       {
         "path": "frontend",
         "name": "Frontend"
       },
       {
         "path": "backend",
         "name": "Backend"
       }
     ],
     "settings": {
       // Project-specific settings
     }
   }

3. You can still use .vscode/settings.json in frontend and backend folders for project-specific settings.

4. Open the workspace file in VS Code using "File > Open Workspace from File...".

[adam-azarchs]

That still doesn't solve the problem of wanting per-project configuration that is checked into git for consistency across all users on the team, e.g. files.insertFinalNewline, to coexist with settings which are more of a personal preference, e.g. pylint.severity. You can of course just leave those settings out of .vscode/settings.json and set them at the workspace, machine, or user level, but it's still problematic that the .vscode/settings.json can't be used to provide "sensible defaults" since it overrides those other settings locations.

While I think being able to extend settings like this is very important, TBH simply being able to override the priority with which .vscode/settings.json was handled would solve maybe 60% of the problems I have with the current setup.

[AdoKevin]

This extension appears to add this capability, has anyone here tried? https://marketplace.visualstudio.com/items?itemName=KalimahApps.tabaqa

This extension seems to provide a good workaround for this issue. Just need to add .vscode/settings.json to .gitignore and submit tabaqa.json to git. Then settings.json for each project or directory is dynamically generated by the extension based on tabaqa.json. The only problem is that if you are collaborating in a team, every collabrator will need to install this extension and understand how it works.

Anyway, hope that the VSCode team can provide first-party support for this.

[bravely-beep]

I'm extremely surprised that this issue has been open for almost 8 years now, and still no solution has been implemented.

Bumping this issue as I'd also find this feature very useful.

[i111010010100]

I also see a great need for this feature, so +
And a huge thank you to the VSCODE developers for their work!

[T-256]

FYI, new Profile Editor allows you to inherit settings from other profiles when creating new profile.

You can choose to either create a new profile by copying the contents from a
Profile Template or from an existing profile

[jmevel]

@T-256

You can choose to either create a new profile by COPYING the contents from a Profile Template or from an existing profile

This is in no way an extend from another profile, it's only a simple one time copy of all settings.

[chipbite]

@T-256 : s/inherit/copy/

[orimay]

Yes, this is really needed

[alexrecuenco]

I might be late to the party, but given how profiles work:

It would be great if at the very least there would be at the user configuration level

1. a key called extendsFromDefaultProfile that is set to false by default.
2. If however extendsFromDefaultProfile==true, your user settings inherit from the Default profile. Overriding any properties it defines itself. (Same merge strategy that it currently does with Project > Workspace > User, it would be Project > Workspace > User (profile) > User (default))
3. I see that key being only available on the default profile as one option, and another option if it would be available on all profiles (so you choose which inherit/doesnt)

Right now you either have the exact same settings as the default profile on another profile, or you have a COPY that you need to maintain for each profile.

The best way, of course, would be if you could extendsProfiles: [...] and that is an array of profiles available to the user, ignore any profile that isn't on that list.

Either way, it would allow a user to subscribe to a profile from their company/workplace/python recommendation, etc, and to be able to have their own customization to it..

[alexrecuenco]

@T-256

You can choose to either create a new profile by COPYING the contents from a Profile Template or from an existing profile

This is in no way an extend from another profile, it's only a simple one time copy of all settings.

Actually, you don't have to copy the contents. That is proper inheritance from the default profile. :)

• You can share the default config currently with any of your profiles. And if you make any modification in any profile, it affects all of them. That is what @T-256 is showing

However, if you do that, the default settings are shared across all of them. There is no way to get the default as base and then have overrides on another profile

[d90mhz]

FYI, trying to rollout CoPilot across 5k+ developers... early adopters love it so far.

However, whether it's entirely true or not, people believe they need to first switch to VSCode to be effective with CoPilot.

This issue is preventing large teams from adopting. Teams working on large monorepos who are used to having others configure project setting defaults for them while still having ultimate override control for debug/diagnostic/performance reasons.

@microsoft: you will get much better adoption of CoPilot if this trivial enhancement is resolved.