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

[alexreg]

@bersbersbers Frankly, rather than petulantly leaving downvotes, it might be wise if you chipped in with your opinion!

In my opinion, it's important that Microsoft knows what poor form it is to leave an important issue like this unaddressed for so long, and the more people that voice that opinion, the better. Maybe they'll actually do something about it then!

Edit: In particular, it's quite disappointing that the suggestions/offers of some people here (including my own) haven't even received responses. Is it not the spirit of OSS development to leverage the contributions and goodwill of users? Frustration seems like an eminently fair response at this point.

[geekley]

Sometimes, in certain specific cases involving local path settings, you can work around this by using git-ignored symlinks in the workspace, and instructing (e.g. in README) anyone cloning the repo to manually create those symlinks in the local repo, pointing to whichever path it should be on their machine. E.g., something like:
ln -s ~/myLocalLibs/fooLib .symlinks/fooLibPath
"mySetting.fooLibPath": "${workspaceFolder}/.symlinks/fooLibPath"

But this workaround only works in very specific cases (relative path or variable substitution must be supported by the setting), and wouldn't be needed if we had this feature.

[madcapnmckay]

I work on multiple projects and have multiple vscode instances open at a time. I wanted to use the Peacock plugin to vary the color of each window. I can't do that without checking in the change to settings.json for everyone.

Surely it would be clearer and more ergonomic to have a user.settings.json and workspace.settings.json where the former can be added to .gitignore?

[jadnhm]

I have the same need for this feature as others have expressed.

Is there some internal debate about whether this would be useful or not? Even if it were introduced as a 'power user' feature and only supported the actual override file and came with no UI I think most of us would be super happy with that.

Hopefully there is still some momentum on this on the vscode team!

[SimonRev]

@jadnhm , I agree. There are a bunch of similar requests and part of me feels like the team hasn't really understood what we are asking for. However, Visual Studio has done this for ages and it really feels like something natural for VS Code.

It also feels like the basics have to already be in place -- there is a master set of settings (the global ones) and then overrides in the workspace one. This would extend the chain one step farther and have more overrides in the local one.

[jadnhm]

Open question to any of the many many people watching this issue - is there anything we can do to further the case for this work or get attention from the vscode dev team?

The ticket has been open a LONG time and I feel like it's just swirling in the backlog with no hope of ever making it into someone's actual line of sight for real work anytime soon. This is the fate of many important tickets on many projects, sadly 😔

A few people have even offered to supply PRs that would implement this but I'm afraid that work would be wasted if there is no hope of getting it approved/merged.

I can come on here and leave a comment every week and be a PITA but I feel like that will just get the ticket closed without due consideration....

Ideas about how to raise the profile of this issue?

[jadnhm]

Just jumping back in to say that at least 13 of us still care about seeing this issue make some progress haha 📢

[TomasB]

@sandy081 is there any way this can be escalated? Or maybe there is an outstanding issue/consideration that prevents this to get some traction, in which case it would be nice to get some insights.

[theacodes]

Adding my voice to the choir- I'd love to see this feature, it has specific use cases already specified, and it isn't a massive behavioral change. What would need to be done to move this forward? Would a pull request implementing this be considered?

[rib]

Also joining the choir as I've landed at this issue multiple times over the years and again finding it awkward that there's no way to have local settings for a workspace.

I often want to override common settings that are tracked in git with debug/development settings which should be ignored by git and usually resort to modifying my user settings which is usually a really bad workaround because it then affects all instances of vscode across all projects.

There's such a strong signal here that lots of people would really appreciate having this feature.

Is there any chance of reconsidering addressing this @sandy081 ?

[rib]

I wonder if another active maintainer might be able to give some feedback on how this issue could be progressed somehow. Maybe @Tyriar @meganrogge or @bpasero can give some input here?

[Tyriar]

@rib please don't ping random contributors, we all don't work in this area so you're just giving us more notifications to look at

[jadnhm]

@theacodes

Would a pull request implementing this be considered?

Do you feel you have the knowledge/expertise to provide a PR to discuss? That might get the ball rolling?

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