[Feature] Local Workspace settings

[firelizzard18]

I would like to be able to configure settings that are specific to my user and to a particular workspace. So, 'local' workspace settings?

So there would be three locations for settings (for a single-folder workspace):

• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.local.json

This way, I can add .vscode/settings.json to git, and share project settings such as "exclude node_modules" but I can gitignore .vscode/settings.local.json and add things specific to that project that I don't want to share, such as git autofetch.

I originally thought to suggest .vscode/settings.user.json, similar to how VS Pro handles similar configuration, but that might be confusing.

[sandy081]

@firelizzard18

We have released a new Multi-root Workspace Feature where you can open multiple folders in a workspace. This introduces a new abstraction in settings.

User -> Workspace -> Folder

Settings under .vscode folder are called now Folder settings in a Multi-root workspace. You also have Workspace settings those get applied for complete workspace. For more information refer here.

You can open a folder in a workspace as follows and can use Workspace settings here as user specific workspace settings for the folder.

• Open an empty window and add the folder to it.

Please try it out and let us know if that solves your issue

[firelizzard18]

Using a multi-root workspace, even with only one open root/folder, adds a layer of unnecessary complexity. I'm looking for an additional config file that works with a single-root workspace, so I can have the main workspace config file checked in to source control and the additional workspace config file ignored.

[Aloisius]

Instead of creating new local workplace settings, perhaps keeping settings.json as the local workspace settings file and creating a new shared workplace settings file makes more sense?

That way the extension api #43226 wouldn't need to change and extensions would continue to work as they are currently written.

The only change necessary, I imagine, would be to check to see if .vscode/shared.json (or whatever) existed, load it first, then load .vscode/settings.json.

In my case, the issue is that the python extension writes the python path to settings.json which is different for every developer using virtualenv. The settings I'd like to add to version control and share between devs are files to ignore, unit testing and linting.

[sandy081]

Currently .vscode/settings.json is shared as it is part of .vscode folder. So it cannot be treated as non shareable one

[borekb]

Related issue with some additional use cases: Local settings overrides (settings.local.json) #37519

[segevfiner]

The VS Code Python extension saves python.pythonPath in the settings.json (Outside a multi-root workspace). This is a problem when you want to commit settings.json to share settings, and there are likely other settings extensions might want to customize and save per repository.

It would really make sense to add such a local settings file to solve this. Even better will be to support this for the other json files in VS Code too, allowing you to keep local tasks, debug configurations and such without editing possibly committed files.

It might require some restructuring of the way VS Code handles editing those files. Personally it would make sense for it to edit the local ones by default, requiring you to explicitly move stuff to the shared ones in order to share/commit them.

[lehni]

The suggestion in #37519 to use a workspace doesn't work for all kinds of settings. For example, I can't seem to control "editor.formatOnSave" from the workspace level, only from the folder level.

Having the option to provide settings.local.json would still add a lot of advantages over workspaces.

[ghost]

An example of when this would be truly useful - When I use VSCode for Go, I like to have enableTestOnSave on by default, because most of the time, tests are fast enough to run on save. However, when I'm working with packages that have tests which take more than a few seconds to run, I would like to disable this setting.

I could accomplish this by setting go.enableTestOnSave to true at a user level and to false at a workspace level for those packages. However, when working in a team, there are also shared workspace settings (like which static analysis tools rules to use) that are already checked into version control.

So the only way to accomplish what I want now is to manually toggle the enableTestOnSave feature, which isn't very pleasant.

Note that while I have used a specific feature from a specific extension as an example, there are other features that I would also like to customise on a workspace level, that I shouldn't be checking into version control.

[remcohaszing]

Instead of using ${workspaceRoot}/.vscode/settings.local.json, I believe these settings should be stored outside of the VCS repository. I tend to use git clean -xdf a lot to get a pristine working directory. This would remove the local settings.

My current workaround is to create ${workspaceRoot}/.git/.vscode and symlink it after I remove it by accident. This workaround works, because I believe it’s a bad practice to commit editor configurations. Since I don’t commit them, a symlink won’t override any existing files. This won’t work for merging multiple configurations.

Perhaps VSCode should just look for ${workspaceRoot}/.git/.vscode, ${workspaceRoot}/.svn/.vscode, etc. for additional settings instead.

[firelizzard18]

I stand by my original request, and I consider it the simplest solution to the immediate problem of local settings.

IMO, suggestions such as @remcohaszing's don't fall under "Local Workspace settings" and thus belong in a separate feature request. A better, general solution for those scenarios would be something like "settings.location": { [key: string]: bool } maps specifying where VSCode should look for the various settings files.

[remcohaszing]

I totally agree with @firelizzard18. This is why I originally created #40233. However, it was marked a duplicate of this issue by the VSCode team.

[firelizzard18]

@remcohaszing I believe you meant #56148

[remcohaszing]

Yes, sorry, my bad.

[firelizzard18]

I created #59374 to expand on my suggestion for your use case, since your issue was closed.

[jamietre]

Surprised that this feature still isn't on the roadmap. The inability to override workspace settings locally means it's really hard to share common settings for big projects in a way other than saying "just copy and paste this to your user settings", since anything in the workspace settings becomes the immutable law of the land rather than a starting point.

For example, we might like to set some standard configuration for plugins that we know a lot of people use, but sometimes individual users want to tweak those configs to their tastes. That's impossible now since you can't override any key that's defined in the workspace settings committed to the repo now. Either we leave it out of workspace settings entirely, and require everyone to maintain the default settings themselves, or we impose a specific config on them completely that they can't easily change.

An example of how annoying this can be is when I was working on a public git repo that included scripts.formatOnSave: true in settings.json committed to the repo. This is great, if you happen to use the prettier formatter - which I don't. So every time I saved a file, it formatted it using the vscode default formatter, and broke linting. My options included:

1. install/enable prettier formatter extension before working in this repo, and disable it after each time
2. change settings.json before working on the repo and remember to undo those changes before making a commit

wouldn't it just be a lot easier to allow end-users to control their environment locally?

[OliverJAsh]

As per @sandy081's recommendation, I've been using multi-root workspaces as a workaround for this missing feature. However, there is a significant issue. As per the docs for muti-root workspaces:

To avoid setting collisions, only resource (file, folder) settings are applied when using a multi-root workspace. Settings which affect the entire editor (for example, UI layout) are ignored.

— https://code.visualstudio.com/docs/editor/multi-root-workspaces#_settings

This means all settings for extensions defined in the folder level settings will be ignored! 😒

For this reason, I don't consider multi-root workspaces a solution to this. We need something different!

/cc @sandy081

[sandy081]

@jamietre

An example of how annoying this can be is when I was working on a public git repo that included scripts.formatOnSave: true in settings.json committed to the repo. This is great, if you happen to use the prettier formatter - which I don't. So every time I saved a file, it formatted it using the vscode default formatter, and broke linting.

If the repo you are using is configured with settings from an extension, then the repo should recommend that extension to install right? It means all users using this repo should have this extension installed and you can enable this extension only for that workspace? Is not it the right solution instead of using different formatter or disabling this setting?

[sandy081]

@OliverJAsh Yeah agreed, MR workspace does not work, if there are non resource specific settings in folder settings.

I would like to gather those settings which you want to configure at folder level but you do not want to put in .vscode/settings.json. Some examples I gathered from this issue are

• git.autofetch
• override static analysis settings
• library paths per workspace

[jamietre]

@sandy081
If the repo you are using is configured with settings from an extension, then the repo should recommend that extension to install right?

Why should I be required to do anything in my own environment I don't want to? There should be no requirement that anyone use "format on save" at all if they don't want to. There should be no requirement to install an extension just to not be broken.

It means all users using this repo should have this extension installed and you can enable this extension only for that workspace? Is not it the right solution instead of using different formatter or disabling this setting?

I'm not using workspaces; I don't want to use workspaces; there are other consequences of using workspaces.

The answer to a problem shouldn't be "why don't you just do a whole bunch of stuff that you don't want to do?" Yes, there are workarounds, but they are annoying, inconvenient, intrusive, and maybe I simply don't want the behavior at all! Why should I be forced to use an autoformatter if I don't want to? This is an IDE, not a build environment. Nobody has to use VS Code at all to work in any code base, so why shouldn't I be able to use it in the way I see fit without going to extreme measures?

The actual problem here is that there's no way to override workspaces configuration settings, not that I haven't installed the right extensions. Users should be able to override any setting locally, period. It just seems so obvious to me that I should be able to control the way my IDE works without changing files committed to the repo or setting everything up in some complex way that's not just the default behavior when opening up a folder containing code.

Why can't we just have a file that supersedes workspaces settings? Or why can't the existing user settings take precedence over workspace? None of this prevents people from doing stuff they already do, it just lets each user have the final word in what settings are in effect in their own environment. I really can't think why anyone wouldn't want this.

[sandy081]

@jamietre All can'ts can be done.

Adding a new level makes settings story more complicated in terms of UI, API and UX. We generally want the product to be simple and easy to use. But at the same time we accept and build new features even though they are complicated when they are worth. We would like to see if the existing solution will work out for new requirements and if not we will work on it given that it meets our priorities.

Please note that this is being discussed in our planning and it is in the queue.

[munro]

I would love this feature. 🥺🙏

I really like the idea of adding the ability to import another settings JSON file— then it would be self documenting how the local config is being pulled in. There is another issue tracking this feature idea: #15909

And then a flag could be set if missing (the local file .gitignored / not commited to repo) — #15909 (comment)

[tokiory]

bump!

[jadnhm]

Are the 👎s for the action of 'bumping' or for the ticket in general? I don't understand....

[kroppt]

Are the 👎s for the action of 'bumping' or for the ticket in general? I don't understand....

It's probably for the bumping. This is not a forum. The default view when looking at issues is sorted by creation time, not last updated time. Given that there's no benefit to bumping, when you have 600+ people interested in an issue, bumping is just noise.

For what it's worth, I'm currently looking at what it would take to implement this in VSCode.

[liubin595338764]

I also need this feature. For example, I am working on multiple projects simultaneously and I want to set different editor theme colors for each project. However, I cannot submit this setting because it would affect my colleagues who may not like my chosen theme color. Therefore, I need a settings.local.json file to configure it.

[tvardero]

I need this feature, my use case is as follows:

We (a team) develop a game for gamejam using Godot. Godot engine is used as a player and scene editor, while VS Code is used for text files editing (scripts, markdown, configuration, etc..).
There is an extension "godot-tools", which enriches development in VS Code. For it to work fully it needs a path to Godot editor executable file.

Extension stores path to Godot.exe as a workspace setting (.vscode/settings.json):

{
    "godotTools.editorPath.godot4": "c:\\Program Files\\Godot_4.2.2\\Godot_v4.2.2-stable_win64.exe"
}

The thing is: I develop on multiple computers (I switch to my laptop when there is a blackout and I can't use my desktop PC). Godot is installed in different locations on both of my computers. On laptop it is on drive D:/ (no free memory on C:/), on desktop it is on C:/ (1 TB space, no drive D:/ at all).

This makes storing in user settings difficult, as user settings are synchronized.
Storing as workspace settings also is not viable - the same issue as user settings. but also team-shared (and each team member might have their own Godot installation path).

Machine-specific, non-synchronized setting will be a perfect fit.

P.S.:

Also, would we work on multiple Godot projects, there are Godot versions 3.5 and 4.2. And they are different executables stored in different paths. Godot-tools extension support boths and is used for both, but we need to path to exe file depending on which project we are working on.

So ya, settings.local.json is a must.

[geekley]

@tvardero I think a workaround for your specific case is:

• use workspace settings for any paths
• path points to a symlink in the workspace
• symlink pointing to the external program location
• you can have the setting in version control
• symlink itself is git ignored
• for your team, add instructions to create the symlink on a README

That's what I do in my flatpak'd Godot+.NET project, I use the plugin for Godot and build scripts for C#, and everything works, pointing to the programs in the flatpak location.

This feature is needed because not all settings are about paths, but for the ones that are you may be able to use symlinks, ln -s ... on Linux (I forgot what is the Windows equivalent).

Btw, did you know you CAN use forward slash on Windows paths just fine?

EDIT: nevermind, I think the path settings need to be absolute paths in this case, if so this solution doesn't work well... :/

[voxpelli]

This makes storing in user settings difficult, as user settings are synchronized.

@tvardero Not true, you can manually opt-out any setting from being synced and the creator of the extension can make that the default by tagging the setting as a machine specific setting.

What you can't do is to opt out of workspace settings overriding user settings, and that's what this issue (or at least was what #206802) is about.

[blackliner]

Wasn't this solved in the unix world by using a settings.json.d folder that contains config files that get applied?

[SimonRev]

I am unclear how a settings.json.d solves the problem. Also, this request would seem to apply to Windows installs as well.

I do feel like this problem is difficult to describe in a way that people who don't need this feature understand the request.

Maybe I can provide something concrete examples:

My user settings.json is full of a bunch of settings that apply just to me -- not the entire team, but that I want applied to every single VS code instance. Here are some sample settings:

    "C_Cpp.vcFormat.newLine.closeBraceSameLine.emptyFunction": true,
    "C_Cpp.vcFormat.newLine.closeBraceSameLine.emptyType": true,
    "csharp.debug.console": "integratedTerminal",
    "editor.unicodeHighlight.ambiguousCharacters": false,
    "terminal.integrated.fontFamily": "JetBrainsMono Nerd Font Mono",
    "window.titleBarStyle": "custom",

Now, my for my specific project there are settings that apply to that specific git repo and are shared among the entire team via the .vscode/settings.json file:

    "cmake.sourceDirectory": "${workspaceFolder}/projectName",
    "cmake.buildDirectory": "${workspaceFolder}/projectName/build",
    "cmake.automaticReconfigure": false,
    "json.schemas": [
        {
            "fileMatch": ["file1.json"],
            "schema": {
                "allowTrailingCommas": true,
                "allowComments": true,
            }
        },
        {
            "fileMatch": ["file2.json"],
            "schema": {
                "allowTrailingCommas": false,
                "allowComments": true,
            }
        }
    ]

Finally, there are settings that I want applied just for ME and just to that particular repo. The major use case I have is because I frequently check out multiple copies of the same repo on different branches and I like to change the title bar color of VS code so that I can easily distinguish which branch I am using.

    "workbench.editor.decorations.colors": true,
    "workbench.colorCustomizations": {
        "titleBar.activeBackground": "#525",
        "titleBar.inactiveBackground": "#313",
    },

I don't want to check these specific changes in to my git repo and the rest of the team doesn't want my color customizations to VS code. Unfortunately because these share the same .vscode/settings.json file, there is no way to not check those changes in without manually remembering to revert the changes before doing a git push, which is easy to forget. The request is that there be a 3rd tier of settings file that can be NOT commited to get but apply just to the project.

In other words: The current behavior is:

• First look in ${workspaceFolder}/.vscode/settings.json
• If not there, look in ${user settings folder}/settings.json
• If not there use the default.

The new behavior would be:

• First look in ${workspaceFolder}/.vscode/settings.user.json (or whatever name makes sense)
• next look in ${workspaceFolder}/.vscode/settings.json
• finally, look in ${user settings folder}/settings.json
• If not there use the default.

There are probably other approaches that achieve the same thing, that I would be open to. But the key thing is to support per user, per workspace settings, in addition to the existing per-workspace settings and per-user settings.

[blackliner]

I am unclear how a settings.json.d solves the problem

Ok, sorry I kept it a bit short, assuming the approach would be clear. settings.json.d would be a directory inside .vscode: ${workspaceFolder}/.vscode/settings.json.d. This directory would contain *.json settings files, and taking your new behavior from your previous post, it would be applied like this:

• First look in ${workspaceFolder}/.vscode/settings.json.d/*.json and apply them in order
• next look in ${workspaceFolder}/.vscode/settings.json
• finally, look in ${user settings folder}/settings.json
• If not there use the default.

It would be the most generic solution to solve your and many other problems we have. You can .gitignore any prefixes in that directory to keep them for "personal" use, or check some of them in to better organize your huge settings.json.

Reference:

• Why/What /etc/apt/sources.list.d?
• check man sources.list

[akwodkiewicz]

I don't believe there's a need to make it a directory. For one, the .d convention is not that obvious to people whereas having a single settings.user.json override is rather straightforward. And more importantly, if you think about it, there's no reason for a directory with overrides, since the single use-case of the feature is to allow a single person to provide a set of local overrides for workspace settings. I don't see a reason somebody would stack their own configuration overrides in multiple files and any scenario involving other people committing files into this folder would make it effectively regular workspace settings.

So a single settings.user.json should do just fine (if not better).

EDIT: Ok, I re-read the last message and only now I got the part about reorganising settings. Yeah, the directory approach is more generic and still allows for a single (conventional) settings.user.json inside it with the help of .gitignore. However, you still need to define how the precedence of the configs is determined (I assume alphabetical).

[SimonRev]

@blackliner , thank you for that detailed explanation. While I agree with akwodkiewicz, that that may be overkill, it would certainly suffice to solve my pain point. If implementing that solves issues at multiple levels in VS Code -- or could be generalized as a solution for multiple files, I would be all for it.

[MuMaestro]

I read most of this issue, and it seems its on the backlog of the project.
Can @sandy081 give us an update ? Is there a feasible future where this is implemented ?
Or there are too much diversions of use cases to discuss here ? Would making a new proposal make it better ? For cleaning up other comments, and focusing on the main needs of the feature

[voxpelli]

Or there are too much diversions of use cases to discuss here ? Would making a new proposal make it better ? For cleaning up other comments, and focusing on the main needs of the feature

I tried making a separate narrower issue, it was closed as being out of scope: #206802

[msct]

Dec. 14, 2017

So there would be three locations for settings (for a single-folder workspace):

• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.local.json

This way, I can add .vscode/settings.json to git, and share project settings such as "exclude node_modules" but I can gitignore .vscode/settings.local.json and add things specific to that project that I don't want to share, such as git autofetch.

Dec. 15, 2017

Using a multi-root workspace, even with only one open root/folder, adds a layer of unnecessary complexity. I'm looking for an additional config file that works with a single-root workspace, so I can have the main workspace config file checked in to source control and the additional workspace config file ignored.

April 21, 2020

My initial proposal was very simple: read settings.*.json in addition to settings.json, from ${workspaceRoot}/.vscode.

I'm trying to follow the progress of this thread over the years.

I would propose leaving settings.json alone, and to introduce a single settings.dist.json file instead. It could be safely source controlled.

• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.dist.json

VSCode doesn't ever have to write to the settings.dist.json file, and preferably it does not. It just reads default values from it.

Values here would still be considered Workspace settings. Just consider each value the "Workspace Default Value". The name of the file doesn't actually matter to me, but the concept is important to many.

I don't need a corporate-level control over the developer environment, I just want working defaults so their environment works as intended out of the box and continues to be easily customizable.

[jadnhm]

So well put @msct

I don't need a corporate-level control over the developer environment, I just want working defaults so their environment works as intended out of the box and continues to be easily customizable.

[xamix]

I also tryed to get something like this and so I upvote for this feature.

I tryed to create a Workspace file with single root folder in Vscode 1.93.1:

"folders": [
		{
			"path": "."
		}
	],

However it seem that some settings are then not overridable by the Folder .vscode/settings.json file
For example if you have in your Folder .vscode/settings.json the following params:

"workbench.colorCustomizations": {
....
}

Then all the color customization is not applyed anymore because the Workspace seem to take this over even if it is not declared in the workspace file.
Also I got a message in the .vscode/settings.json on this object which say:

This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly.

I also got this message on a number of other settings like "clang-format.executable"
So workspace is not usable to configure per project AND user

Please implement something which can help us.

Regards

[fudanglp]

I am unclear how a settings.json.d solves the problem

Ok, sorry I kept it a bit short, assuming the approach would be clear. settings.json.d would be a directory inside .vscode: ${workspaceFolder}/.vscode/settings.json.d. This directory would contain *.json settings files, and taking your new behavior from your previous post, it would be applied like this:

• First look in ${workspaceFolder}/.vscode/settings.json.d/*.json and apply them in order
• next look in ${workspaceFolder}/.vscode/settings.json
• finally, look in ${user settings folder}/settings.json
• If not there use the default.

It would be the most generic solution to solve your and many other problems we have. You can .gitignore any prefixes in that directory to keep them for "personal" use, or check some of them in to better organize your huge settings.json.

Reference:

• Why/What /etc/apt/sources.list.d?
• check man sources.list

I also propose ^

[rubensa]

I am unclear how a settings.json.d solves the problem

Ok, sorry I kept it a bit short, assuming the approach would be clear. settings.json.d would be a directory inside .vscode: ${workspaceFolder}/.vscode/settings.json.d. This directory would contain *.json settings files, and taking your new behavior from your previous post, it would be applied like this:

• First look in ${workspaceFolder}/.vscode/settings.json.d/*.json and apply them in order
• next look in ${workspaceFolder}/.vscode/settings.json
• finally, look in ${user settings folder}/settings.json
• If not there use the default.

It would be the most generic solution to solve your and many other problems we have. You can .gitignore any prefixes in that directory to keep them for "personal" use, or check some of them in to better organize your huge settings.json.
Reference:

• Why/What /etc/apt/sources.list.d?
• check man sources.list

I also propose ^

The solution also looks good to me. The only inconvenience I see here is that, to only personalize a setting in one file, you should have to fully "copy" the content of the original file and then customize it. As an alternative there might be a mechanism to mix and match the file contents (following the precedence order) but, in some cases, it is not obvious how to do that (fully override, add not present, delete some parts...).

[BertoMejia]

• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.local.json

I agree with the ${workspaceRoot}/.vscode/settings.*.json approach, where this file would override the settings.json file.

• First look in ${workspaceFolder}/.vscode/settings.json.d/*.json and apply them in order
• next look in ${workspaceFolder}/.vscode/settings.json
• finally, look in ${user settings folder}/settings.json
• If not there use the default.

In general, I like the .d folder approach the way it was used for APT.

However, in a VS Code project, I don't ever see myself creating more than one settings file. VS Code does not have that many settings where I need to create separate files for different settings. I also don't ever see the need to enable or disable settings files.

For those reasons, my opinion is that the single settings.*.json approach, where each one of the files below would override the previous one would be simpler and better.

• default settings
• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.*.json

[MuMaestro]

For those reasons, my opinion is that the single settings.*.json approach, where each one of the files below would override the previous one would be simpler and better.

• default settings
• user settings
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.*.json

THIS, could even be configurable in global settings, the user should be able to decide what supersedes what.