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