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.

[ineol]

Hi,

are there any updates on this?

thanks!

[sandy081]

@mikelward Thanks for giving the breakdown. Trying to understand why you did not want to keep tabSize... settings in global settings? Are you syncing global settings between your personal and company machine?

If you are using any external tool/extension for syncing, I think the easier and better solution could be that if the tool can provide an option to sync only a list of settings you would like?

[sandy081]

To all those who are requesting for local workspace settings, here is the issue #40233 that tracks it. This issue does not cover it.

[phryneas]

@sandy081 I personally would like to sync most of my settings with nix home-manager.
Thing is, everyhing related to nix and nixos creates read-only files owned by root.

So I won't even be able to just modify the font size for a moment because the config file is read-only.

Thus, I would need a "global global" config files (which is managed by nix), a "global" config file (for this machine, that can override the "global global" settings") and then, further down the road I have my project-specific settings.

[The-New-Guy]

@sandy081

If you are using any external tool/extension for syncing, I think the easier and better solution could be that if the tool can provide an option to sync only a list of settings you would like?

In my case, it is Dropbox that is syncing my settings files from one machine to the next. Dropbox is of course not aware of VSCode settings, it's just syncing the files. I then point a symlink to that Dropbox file and thus when I updated a VSCode setting on one machine, I don't have to remember to update it on another machine (I have 4 development machines not counting terminal servers). So in my case, it really isn't possible for the external syncing tool to do this separation of settings.

For my use case, it is generally path settings that differ from one machine to the next. For instance, the paths I use when on Windows are of course drastically different than the paths I use on Linux. They can also be different between two different Windows machines if say there is a path to my user folder and the user is different on those two machines.

As it is now, the only way I can handle this situation is to have a full complete settings file for each of my machines that only differ with the paths used. Which means for every setting change I make, I have to also make it in every machine specific settings file. This of course is not ideal and very problematic. So much so that on my Linux machine I just deal with having a few broken extensions rather than trying to keep multiple files up to date. On my Windows machine I can get around some of this by just having more symlinks (i.e. C:/Users/WorkUser -> C:/Users/HomeUser). However, that only works on some of the paths and others I just deal with it not working.

[ELLIOTTCABLE]

Hey there! Just 👍 voice that "workspace settings" is not the same as "multiple global (non-workspace-specific) settings files."

One mention came up of 'making the syncing tool' understand the settings file, and explicitly decide which settings to sync and which not to: well, for most of us I daresay, Git is the syncing tool. And I really strongly doubt Git is going to land explicit support for VScode settings-files. :P

At the moment, if you don't want all settings synced into your dotfiles repository, you're a bit SOL. I, for instance, have to use interactive-stage tooling, and simply leave parts of the changes uncommitted (theme, which I change often and never have any desire to sync; font-size and such, some machine-specific PATHs ...), and just deal with the fact that since I started to use VScode, my dotfiles directory is never going to be in a clean state anymore. 0=

Anyway! Just, again, 👍 for this as an actual feature; it is not something that's easily work-around-able!

[jetersen]

I like to have this feature as well as I keep my settings.json in git and in the open
Would love to have this for keeping secrets out of my git repo. Some extensions are not keen on encrypting secrets properly.

[FranklinYu]

I find this feature useful to me for keeping a local configuration. A potential issue is how do we merge them? Consider this in settings.json:

{
  "foo": [1, 2],
  "editor.includeConfig": "settings.local.json"
}

and following in settings.local.json:

{
  "foo": [4, 5]
}

Do we expect foo to contain two elements or four?

[sandy081]

Depends on it handles secrets that might be in the settings.

You can ignore these settings from sync. Are you expecting more?

[jetersen]

See my previous comment: #17634 (comment) see my usage here: https://github.com/casz/dotfiles/blob/master/vscode/settings.json

[sandy081]

Ok. Ignore setting feature will solve your use case.

[ithinkihaveacat]

Given the settings sync feature, would like to know if there is a still need for this feature?

@sandy081 As I understand it, this issue is about supporting machine- or environment-specific configurations. If this is part of the sync feature, then great, otherwise I think this issue is still relevant.

(It seems like this might be covered by #89627 and/or #88625 but I'm not sure whether they will actually be part of the sync feature on not.)

[sandy081]

@ithinkihaveacat

We already support ignoring settings to sync. You can select a setting and ignore it from sync and this setting will not be synced. Lets say if you ignore window.ZoomLevel setting then it will not be synced in other machines. Each machine can have it's own window.ZoomLevel value which will not override other machine's value during sync. If this is what you meant by machine specific configuration, then its already implemented.

#89627 is different and more advanced and #88625 is for platform specific extensions.
and #5595 is to allow platform specific settings.

[ithinkihaveacat]

@sandy081

You can select a setting and ignore it from sync and this setting will not be synced.

Oh great, that certainly sounds sufficient for my use case! Do you have an issue describing that feature? e.g. what the syntax is? I couldn't find it.

[phryneas]

Given the settings sync feature, would like to know if there is a still need for this feature?

Yes. I'm syncing all my configurations in a shared dotfile git environment.
I'd like to use that approach instead of one "sync feature" per software, which can get quite unwieldy very fast. Nonetheless I want to keep per-machine-settings and synced settings, thus the requirement of multiple config files that get merged.

[sandy081]

@ithinkihaveacat We are planning to preview it for next 1.44.0-insiders release and you can find this in the release notes then.

@phryneas I see your reason of using separate files when you are using external sync feature like dotfiles repo.

Given that we support this in OOB sync feature, and I am not sure how many users engaged in this issue might have this issue I would close this issue and create a fresh issue for those who still want this?

[FranklinYu]

@sandy081 I would recommend leaving this issue open until the OOB sync feature is released, at which time everyone on this thread can examine whether it works for them.

[sandy081]

Sure. We are planning to launch settings sync preview from 1.44 insiders which is planned to release on next Monday. Will update you once it is released. Would be happy to get the feedback.

[sandy081]

All, As you know from our latest release that Settings Sync feature is previewed in insiders. So, please try out the feature using our insiders and provide us with the feedback - https://code.visualstudio.com/insiders/

[fgarcia]

I am a bit overwhelmed by the huge power of Settings Sync. After a quick overview I am impressed but also a bit sad thinking that a more basic solution might not be implemented.

I tend to sync all my configuration and dotfiles across 4 computers: 1 Linux, 1 Mac and 2 windows. Windows is the main problem because I cannot symlink config files into my unique repository, so something as basic as load, extend or just stack settings from a folder (like vim runtimepath) would help a lot. Also when working on multiple project/teams, a good old app folder config that one can diff and version control is really nice. Even environments where an external internet connection is not possible for legal/certification reasons.

Requiring a Microsoft Account (or a GitHub one as the extension needs) seems a bit overkill. I am sure it will cover most of my pain points, but please consider implementing too the more basic solution that does not depend so much on capital/human investment. It easier to trust on solutions with low maintenance demands.

[alexrp]

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.

I hope this use case won't be overlooked as it is not covered by Settings Sync. It's very unfortunate that you cannot share .vscode/ files in source control without, at the same time, making it so that other developers cannot easily add their own local workspace settings on top (these would show up as changes in source control).

[mclayer]

Our team also needs the ability to share per folder settings, but with the ability to override them locally. e.g. when all team members except one agree with some settings. Currently we haven't optimal solution when everyone is happy and productive.

[sandy081]

/duplicate

From the description of the issue - it seems to be similar to #5595. Hence marking it as a dup.

[pavlodenysov-vizio]

@sandy081 #5595 is not exactly the same. I may have 2 Linux machines that I want to use different settings on.

[sandy081]

Right, got it.

[ctf0]

+1 to this as well, except for a slightly different use case,

when using something like https://github.com/antfu/vscode-file-nesting-config the settings file become very big to parse and it slows down the whole thing even u try to just open the settings editor.

another example would be something like https://github.com/shanalikhan/code-settings-sync in case u have settings for multiple machines/hosts u use ex.

• // @sync host=home os=windows
• // @sync host=home os=mac
• etc..

there are amillion other extension that can quickly bloat the settings file & separating the config between multiple files will surely make things easier to organise & quicker for the editor.

btw this is already possible with theme files ex."include": "./syntax.json"

[SebGt]

Hi,
Please, any updates or ETA?
Because all other issues opened related to the same topic are closed because they duplicate this one but I don't see any progress on this one.
Thanks

[sandy081]

It seems this is a duplicate of following features we already have or working on

• Platform specific settings - From description
• Local Workspace Settings
• Profiles
• Settings Sync

Hence closing this as duplicate of all these features.