Vscode: 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 :smile:

[andreineculau]

@sandy081 am I correct in saying that you're advocating that large groups that share common settings should create their own extension? https://github.com/Microsoft/vscode/issues/15162#issuecomment-262449840

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.

[sandy081]

Closing this as the multi-root workspaces solve the issue. Others please use https://github.com/Microsoft/vscode/issues/40233 for non sharable workspace settings.

[qtiki]

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.

[sandy081]

@qtiki Makes sense. Reopening for your scenario and updating it in the description

[DJMcNab]

I now dual-boot Windows and Ubuntu, and was looking for a way to share my settings between them. This would be my use case for a feature like this.

[haugerbr]

@DJMcNab you might be better off with something like this: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

[huan]

+1

Should be just like the new TypeScript 3.2 feature: tsconfig.json inheritance via Node.js packages

TypeScript 3.2 now resolves tsconfig.jsons from node_modules. When using a bare path for the "extends" field in tsconfig.json, TypeScript will dive into node_modules packages for us.

{
    "extends": "@my-team/tsconfig-base",
    "include": ["./**/*"]
    "compilerOptions": {
        // Override certain options on a project-by-project basis.
        "strictBindCallApply": false,
    }
}

Here, TypeScript will climb up node_modules folders looking for a @my-team/tsconfig-base package. For each of those packages, TypeScript will first check whether package.json contains a "tsconfig" field, and if it does, TypeScript will try to load a configuration file from that field. If neither exists, TypeScript will try to read from a tsconfig.json at the root. This is similar to the lookup process for .js files in packages that Node uses, and the .d.ts lookup process that TypeScript already uses.

This feature can be extremely useful for bigger organizations, or projects with lots of distributed dependencies.

[superole]

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

That would solve one use case that I see for this feature: -The ability to open Vs Code in a subfolder of a parent project and still use the launch/settings/tasks of the parent project.

I can use multi-root workspace to achieve this, but that really clutters up my workspace, since I then include all the parents stuff and all siblings stuff and my focus folder is included twice. It works, but it is not pretty.

[stiltet]

I 100% agree with @superole

[joem-msft]

My team has an Open Source repo that contains many separate projects. Each project is usually independent from all other projects. We want to make it so that each project can be opened alone (single-folder workspace) yet they should share the same base settings as all other projects in the repo. We can see there needing to be the following setting files:

// {repoRoot}/configs/repo-settings.json
{
    "editor.insertSpaces": true,
    "[json]": {
        "editor.detectIndentation": false,
        "editor.tabSize": 2,
        "files.trimTrailingWhitespace": true
    }
}

// {repoRoot}/configs/projects-settings.json
{
    "$extends": "./repo-settings.json",
    "json.schemas": [
        {
            "fileMatch": [
                "/apiDefinition.swagger.json"
            ],
            "url": "http://json.schemastore.org/swagger-2.0"
        }
    ]
}



md5-6072d494537f55b7cc6cca41a0a31446



And some shared tasks:



md5-e39668342d83c8acb3d5ecfce836f081




And then in each project, we could simply have the following as the default template



md5-d731267aaf92d5a0201a617de56e1dfa



```javascript
// projects/MyProjectA/.vscode/tasks.json
{
    "$extends": "../../../configs/projects-tasks.json"
    // Custom project-specific overrides would go here
}

And the same similar template for sample projects, but they'd be able to choose to extend a different settings file.

This would require:

1. explicit declaration of the settings file to include, using paths relative to the current settings file.
   1.a. Feel free to choose some property name for this. I've used "$extends" in the examples above.
2. recursive extending.
   2.a. Would need to detect circular extends.
3. Allow this to work with launch.json, tasks.json, etc.
4. Resolving of variables like {workspaceFolder} should be resolved AFTER it's included via an $extends.
5. The originating setting file would determine the precedence (e.g. workspace vs user, vs folder). Simply treat the expanded settings.json file in the place of that scope.

[peredin]

This would be a nice feature, I'd like it myself for sharing a base vscode configuration across my own computers.

[paparent]

I'm quite interested in that feature!

Yes, having ability to extends from a local setting that is git ignored that would be nice.

In a mono repo too, with workspaces, so we can have base settings such as linters config and such.

[mchelen-gov]

wanted to highlight for folks:

• workaround
• https://github.com/microsoft/vscode/issues/40233 non-sharable workspace settings issue

[ladjzero]

It would be great to share workspace settings between micro-service projects.

[RobertLowe]

extends seems like an elegant and simple solution

[hrobertson]

In my case I'm not currently needing to share settings between repos, just wanting to have a settings.json/js that is checked in and allowing for that to be overridden in a settings.local.json/js which is git ignored.

[lukaszpolowczyk]

The variable $ {commonWorkspacesSettingsFolder} will also be useful, which is the address to a special folder "(...)/Code/CommonWorkspaceSettings" folder in User Settings. (final name, of course, to be determined)

This folder should contain settings that are universal for many projects.

This is my suggestion from my duplicate: https://github.com/microsoft/vscode/issues/38162

[jacobisaliveandwell]

@haugerbr Hello. I see that you're the most recent member to comment.

Similar to .vscode/extensions.json and how it's safe to commit recommendations to a VCS, because even per-workspace extension settings don't modify that file, it would be nice to have a file with sane defaults that are repo/team specific, and are overridden by an individual's settings.json.

I suggest something like shared-settings.json, but I think the OP was shooting for a more generalized solution that could also fit multi-root workspaces. For that, I vote for this comment.

An example use case is repos with complex extension configurations, like Puppet which offers modulePath, and every developer would need to set this manually, or deal with VCS conflicts, or manage settings globally, even though they might be workspace specific. Without having a means of setting per-workspace "shared" or "extended" settings is leading to a poor user experience.

I hope this all makes sense. Let me know if I can elaborate.

Is there any way we can get this some attention? Preferably an assigned engineer? I have no JS devs I can coax into a PR at the moment 😢

[haugerbr]

@jacobisaliveandwell Unfortunately, I don't work on VS code. The member tag is applied to anyone that is a part of the Microsoft organization. You can tag sandy081 who does work on VS code as far as I know.

[jacobisaliveandwell]

@haugerbr Thanks!!

@sandy081 Think you could share your insights on getting this some attention? Thanks.

[sandy081]

Unfortunately no plans at present to implement this. Sorry for saying so.

[jacobisaliveandwell]

This makes me a sad panda