Local settings overrides (settings.local.json)

[borekb]

It would be great if VSCode understood the concept of local settings that optionally override the standard settings.json rules. Specifically, I'm thinking about a file called settings.local.json which, when present next to the settings.json file (both user and workspace), overrides its values.

Two example use cases:

• Workspace settings: in our team repo, we have basic settings in .vscode/settings.json. I'd like to customize some of those without making modifications to that file (Git would see it as changed, I could accidentally commit it, etc.).
• User settings: I use Settings Sync to synchronize my settings between computers but not everything should be synchronized, e.g., window.zoomLevel. That extension explicitly added support for this scenario but it's not very smooth in my experience; it would be better if VSCode had the concept of local-only settings in the first place.

When writing to settings, for example, when I change my zoom level, VSCode would first look if I have the .local file and if it contains window.zoomLevel. If so, it would write to it, otherwise, it would work as today.

docker-compose.override.yml is a good analogy to this.

Originally mentioned in #17634 (comment) but that issue asks for something slightly different.

[sandy081]

@borekb Main intention of settings coming from .vscode/settings.json is to have a shareable settings that all team members working on that project agreed upon. For eg., using white spaces vs tabs. If a team member wants to override such setting then it should be revisited and removed it from shareable settings. We do the same for vscode project and consider as a good practise. I would be happy to know about the scenario which is against above practice.

For User Settings issue, I would ask the extension author to provide support to sync only selected settings.

[borekb]

Code style is an example of something that is "black or white": you're right that such thing should either be enforced team-wide or not shared at all. However, we have some extension settings in our .vscode/settings.json file with sensible defaults but not suitable in all scenarios and to all team members. For example, we have some spell checking suggestions in workspace settings: which file types to check, with what strictness, etc., but I'd like to customize it locally to be e.g. more strict (at the expense of some false positives). That is my local config that does not mean that the team config is wrong; I just have different needs, locally.

I probably agree with your reasoning about User Settings; that sounds like it should be handled by the syncing extension even though in practice, it's slightly problematic.

[sandy081]

@borekb

but I'd like to customize it locally to be e.g. more strict (at the expense of some false positives). That is my local config that does not mean that the team config is wrong; I just have different needs, locally

How about think this problem as follows. A practice defined by a team and one of the team members has a better practice which might makes it more efficient and productive. If so, you can always push that up to the team.

I know, I am talking an idealistic scenario, but I am trying not to introduce a concept which is not required if there is a solution.

[borekb]

Better practice -> we discuss, commit and push .vscode/settings.json.

Different practice, with its benefits and drawbacks -> ... ?

But I see your point about not complicating the product, I just wanted to post this is a top-level issue in case someone else has similar needs. Let's see.

[bdegreve]

I've first put here a comment about the new version of the Python plugin being an issue: it pollutes .vscode/settings.json with a local setting python.pythonPath, which prohibits for version controlling the workspace settings.

But creating a "single-rooted" *.code-workspace workspace, works around that issue just nicely:

• The non-version-controlled *.code-workspace contains your "local" workspace settings that are not to be version-controlled. They merely tell the IDE how you want to edit in this workspace.
• The version-controlled .vscode/settings.json becomes the "folder settings" (possibly one of many) which contains version-controlled settings of a version-controlled folder.

This way, python.pythonPath is stored in the *.code-workspace settings, which truly is local.

The docs even talk in particular about zoomLevel: you must set it in the *.code-workspace settings, and not in the folder's .vscode/settings.json.

[borekb]

@bdegreve That is a nice trick, thanks.

[sandy081]

Closing this in favour of using new Workspace as a solution.
Will reopen if there are more users asking for similar requirement.