Add support for additional global config files (in addition to settings.json)

[archshift]

It would be very helpful for somebody attempting to sync config files between multiple machines if VSCode supported some system for having multiple config files included at a time.

Benefits:

Imagine a config folder structure like this on a developer's mac:

- settings.json -> ~/Drive/dotfiles/settings.json
- settings.local.json -> ~/Drive/dotfiles/settings.my-mac.json

And then like this on a developer's linux desktop:

- settings.json -> ~/Drive/dotfiles/settings.json
- settings.local.json -> ~/Drive/dotfiles/settings.my-arch.json

Using symlinks, then, a developer would be able to have specialized configuration files for each computer, while keeping the vast majority of options synced between both.

Implementation:

I can think of two simple ways to implement this with as little friction as possible.

1. An editor.includeConfig option in the main settings.json
   This might be a JSON array, with support for various different config files. It could also just be a single field.
   Whether or not the option should be recursive is up to the VSCode team.
2. VSCode searches for all config files in the directory matching settings[.foo].json and includes those.

Conflicts:

If going with option (1) above, conflicting config entries should take precedence the later they appear in the includeConfig array.

If going with option (2), the main settings.json file should take precendence.

[egamma]

FYI @bpasero @Tyriar

[Tyriar]

@archshift I'm curious what settings differ across your Mac and Linux configs? Another potential solution is to have .linux/.osx/.windows settings available for all settings instead of just a select few?

/cc @sandy081 @joaomoreno

[archshift]

@Tyriar it's not so much about OSs and more about computers.

Let's say I have a laptop and a desktop (both Windows, for instance), and the two computers have different screen sizes/resolutions. I might want to set editor.fontSize to 12 on my desktop and 10 on my laptop.

This also applies to extensions. If I'm using the Rust extension, which has options like rust.racerPath and rust.cargoPath, the paths might be different from computer to computer.

[borekb]

settings.local.json is something we would use as well.

In our case, this would be on the workspace level: we'd commit .vscode/settings.json to our team Git repo and share things like files.exclude but the developers would be able to define / override the settings in their .local files.

---

BTW this is a common issue with IDEs. We commonly commit something like .idea-tpl instead of .idea to Git, then have some sort of a build script that copies this to the real location. It would be so nice if Code understood this common struggle and provided a way to deal with it elegantly.

[mikelward]

@Tyriar The requested feature is also useful for maintaining separate override configs for home vs. work, or for each client. For example, different default tab size and linter settings. Hard-coding it to only split based on platform would be too restrictive.

[philipmat]

@mikelward Sounds as if workspace settings might be of better use to you.

[larsch]

This suggestion would be useful to us even in the workspace settings alone. Some settings could be shared (commited) and some could be personal or system specific. I have workspaces on multiple platforms and sometimes need to tweak local settings per workspace, e.g. terminal settings, EOL settings, run code settings, file exclude settings, git settings, etc.

[tianjianchn]

Hope this feature will be imported, including launch.json and other setting files.
Separate TEAM shared workspace setting and PERSONAL specific setting.
Just like coding with Class Inheritance :)
Thanks

[mikelward]

@philipmat Here's my breakdown:
global: shortcuts, colors, fontSize, etc.
company/machine: tabSize, rulers, formatTool, pylintPath, etc.
project/workspace: maybe some overrides could be useful, but for me there aren't any

Doing it using workspace settings would mean I'd need to copy my settings for every one of hundreds of projects. And I wouldn't be allowed to check in vscode-specific configs into my projects, so I'd have to re-create them every time I made a new checkout.

Sure I could script it, but supporting a "local" include file makes way more sense IMHO.