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

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

[JettJones]

This is a long thread already, but piling one more user story on top, because it would be nice to see planned work on setting overrides.

At my company, we want to make it easy for new developers to jump in and be productive on our repository. In the same spirit as running lint in CI, we want VS Code to match those formatting rules, but setting this up runs into this thread's settings override issue.

• sharing settings in ${repo}/settings.json does not allow overrides. So someone who wants to not run formatOnSave means the team can't use the tool as a default.
• sharing settings in a code-workspace means (1) new developers need to find that file. As this thread mentions, not all settings are supported in the workspace. Plus if a dev wants to change the set of open folders or just add setting overrides they need to learn a set of vscode details to proceed.

The feature options in thread would unblock my case- either a per-project user override, or particular overrides in the user's home directory settings.json, or even reversing the order so user settings always override project settings. (That last one seems extra disruptive though - it was just what I assumed coming from other tools where user settings win over project specific config)

And one possibly new point - maybe there are two classes of settings:

• Unbreakable rules - I must use the same tabs-as-spaces rule to edit in this repository. Great.
• Suggestions - Settings that say this project loads faster if I don't index temp files, or most folks will benefit from auto-format. But the developer should be able to override these.

If we agree with the classification - the project settings.json could declare some locked settings, and allow others to be overridden. Maybe that's also over-engineered compared to allowing one more layer of override file. But when imagining how this feature supports use cases, thinking about both tabWidth and formatOnSave examples will help cover more cases.

[kajweb]

So, currently Multi-root Workspaces does not support setting typescript.tsdk at the folder level.

When I use monorepo, I encounter inconsistent Typescript versions used in two folders. When I switch projects, I need to switch typescript.tsdk

Is there any good way for me to modify locally without submitting it to the remot?

#233195

[BertoMejia]

One more thing to consider here is a local user settings file that override the synced settings for each local machine.

Consider the following scenario. I have 2 Windows PC and a Linux PC, all being synced. However, you have python 3.10 installed on and 3.11 installed on the others. Granted, this could easily be handled on a project basis using my previous proposal, but it would be more easily handled on a local computer basis, which would make things easier. Furthermore, there are several scenarios where this could come in very handy.

Here is a slightly modified proposal for this feature:

• default settings
• settings.json - user settings (The current settings that are synced)
• settings.local.json - Local user settings (Not synced)
• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.*.json (processed in alphanumeric order)

This should be a robust solution that covers any possible scenario for settings.

Thoughts?

[witcher112]

UPDATE FOR 2024 (my previous comment)

For many months, I've successfully used Workspace Config+ (https://marketplace.visualstudio.com/items?itemName=swellaby.workspace-config-plus) which supplies the exact functionality described in this issue.

Besides having support for settings.local/shared.json it allows you to do the same with tasks.local/shared.json and launch.local/shared.json making it the perfect solution for covering most of the "shared project configuration" stack within VSCode.

The only caveats are:

• everyone on your team has to install the extension (but it can be easily recommended by putting it in extensions.json and making sure that project docs cover that requirement)
• lack of support for "Settings UI" (although I think that it should be somehow possible in the future)

PS. Kudos to @calebcartwright and @swellaby for giving us this extension!

[pete-willard]

My God, this issue is nearly seven years old. Meanwhile Microsoft is busy cramming AI shit into the app instead of actually useful features users asked for.

[j-lakeman]

FYI the scenario OP described can be achieved with chezmoi templates AFAIK