[Feature] Local Workspace settings
firelizzard18 opened this issue · 149 comments
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.
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
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.
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.
Currently .vscode/settings.json is shared as it is part of .vscode folder. So it cannot be treated as non shareable one
Related issue with some additional use cases: Local settings overrides (settings.local.json) #37519
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.
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.
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.
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.
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.
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.
@remcohaszing I believe you meant #56148
Yes, sorry, my bad.
I created #59374 to expand on my suggestion for your use case, since your issue was closed.
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:
- install/enable prettier formatter extension before working in this repo, and disable it after each time
- change
settings.jsonbefore 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?
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
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?
@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
@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.
@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.
@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.
I absolutely understand and appreciate what's involved in making features. I'm just trying to explain why I think this one is so important.
Users of any software, particularly development tools, unless tightly controlled by some corporate environment where everyone is required to use some specific config, should be able to completely control their configuration without having to resort to extraordinary measures or workarounds.
Users should not be forced to install a plugin simply to be able to work effectively with some code base.
Users should not be forced to set up a multiple workspace configuration and add meta-configuration files to work effectively with any code base.
Users should be able to inherit default configurations from a repository, but still be able to easily override them without altering files committed to the repository, to suit their preferences locally.
I think this should be a given with any tool like this, which is why I'm surprised it's been an issue for so long with no good workaround or solution. I'm just trying to make that case here, and explain the difficulties that it creates for us on a regular basis, in hopes that it becomes a higher priority.
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.
Unless I've missed something, the existing solution is to introduce an additional level of settings by using a multi-root workspace. This is a workaround rather than a solution as far as I'm concerned, and doesn't work with many extensions (for example git project manager) that do not expect you to be using a multi-root workspace with a single root.
We would use local settings to allow support for both team-wide settings for a particular project like file associations, but also subjective user-specific changes (for example changing the colour of the title bar based on which project you're working on, or format on save preferences).
I have an extension that changes the colors of the instance of vs code. I this allows each instance to be visually identifiable. The desire is not to have this affect other users.
Currently i use workspace settings but when they get committed and pushed , other team members will get these colors (which is not what I intend).
I would love to see a way to have local settings that are either git ignored or that can somehow solve this in another way.
If there is any further information I can help with or provide, please let me know.
Here is my extension and repo, if it helps to have a use case.
The simplest situation that supports this is: I want different colors for different workspaces (something Peacock addresses at a shared level).
BUT, my coworkers may not want this. So, I want to LOCALLY change the colors of each folder I open up so that I can quickly tell the difference between the open editors. (I regularly have 3 or 4 vs code instances open at a time)
Agree with @johnpapa and @tommck. I want to impose certain workspace settings for my team as well but don't want to have my personal settings affect them also. I also use different colors for different instances which I don't want to permeate in the git repo.
On the other hand, there are certain shared settings which I want the entire team to get. For example, we use Vetur to help with Vue.js development and by default, Vetur doesn't use prettier for HTML formatting. Fortunately, I can override this by "vetur.format.defaultFormatter.html": "prettier" to settings.json, push it to repo and it works for everyone. We also enforce formatting on save to avoid CI failures later.
I also tend to experiment with new features for individual projects as well. I wouldn't want the related settings.json values to go into the .git repo as well. So, this is an actual problem for folks who use VS Code and related ecosystem to work on projects.
The general theme here (it applies to me too) seems to be shared vs private settings. If you look at the problem in that light, it also enables potential future workflows, like automatically adding shared settings to version control or automatically ignoring private ones. Some food for thought for the team.
With so many extensions needing path specific information (The java debug and test extensions are prime examples), and those extensions being store in settings.json, something like this is becoming even more important. Shared vs private settings are extremely important, as we want some settings configured the same across all users, but things like debug which need explicit paths listed really should not be committed, and vscode has no solution to that currently. Please try and see if we can make this issue happen, as its becoming a large problem throughout the entire ecosystem.
Also, I don't want this to delay implementation, but it would be FANTASTIC if tasks.json and launch.json had the same properties. Local versions of both of those would be fantastic as well.
Aren't we just asking to mirror what Visual Studio does with the ".user" files?
It seems pretty logical to me
Simply having the existing user settings file, on mac found under /Users/[user]/Library/Application Support/Code/User/settings.json supercede the workspace settings would be a huge improvement. Even better would be a split configuration per workspace as well, like the original request suggests.
It seems so strange that there's still no way for a local user to override settings committed to the repo, other than having to change committed code and undo it before committing. Our solution to this problem has been to just not add a lot of common settings to the config that's committed to our repo, but it makes it much harder to get new people started up and distribute changes.
This is also an awkward problem with using MS's own Python extension when using the pipenv virtual environment due to the fact that the virtual environment is kept outside the workspace (usually with a unique name per user and folder).
The existing settings scapes are user and (shared/committed) workspace. Where should I put a config entry that points to the virtual environment for this folder?
- user is incorrect as it would affect all Python projects
- workspace is incorrect as this is a local-only path and should not be shared
As a settings.local.json is considered too complex, perhaps there should be a way to extend user settings to include folder/workspace-specific options in a similar way to current language-specific settings. This way the complexity is only visible to those who chose to use it - just like the language-specific settings.
A format like this may work (but a better way to distinguish a path may be desired):
"[D:\\src\\projectfolder]": {
"python.pythonPath": "D:\\venvs\\project-s59tsklj8\\python.exe",
"editor.formatOnSave": true
}A mechanism such as this should probably also support wildcard paths.
Same request. My use case is through jira plugin. Each project I'm working on has a set of different, personal JQL queries that I don't want to commit into the shared settings.json that everyone else has. Putting them all into global user settings on the other hand clogs up the queries. It'd be nice to separate shared project settings from local ones.
(out of curiosity, and apologies for my ignorance)
Is this RFE:
- difficult to implement?
- breaking existing behavior?
- interacting badly with existing systems?
It wouldn't suffice a blind merge of 2 nested structures, marshaled from the settings.json & settings.local.json files?
There is some complexity with UI and API otherwise it is easy to implement.
Assuming that the transfer of specific settings from shared-->local is done by the user, manually, in text-editor, would it still be that difficult?
I mean, since a read-only merging would solve many people's problem right know,
why not push just that, and take the time to complete the UI-write & API part at your own pace
(if ever)?
(all these assuming a blind-nested-merge, not i.e. combining lists from both sources).
There is some complexity with UI and API otherwise it is easy to implement.
"Aside from it being complex, it's easy" 😂
Does the milestone and assignee being set mean we can expect this feature implemented in the next release? (Obviously, the March release has already come out, but I'm curious about this point nonetheless.)
Wow - I'm very excited to see this! Thanks @gjsjohnmurray and @sandy081 ! Let me know if you want a tester of this, as Peacock would certainly benefit from local workspace settings.
@gjsjohnmurray Thanks; very glad to know!
Here is the latest update on this:
- I started looking into this in this milestone (March).
- Came up with some designs and discussed with the team
- We concluded on the approach
- Implementation will be done in next milestone (April).
- Planning to make this feature available in May.
Will update the design approach soon.
@sandy081 Any chance this will be more generic, like allowing local "launch.json" files as well?
Any chance this will be more generic, like allowing local "launch.json" files as well?
Yes
Design
Introduce Path / Resource specific configuration in User Settings
- User can define folder customisations in user settings using path / resource overrides. For example user can add following to the user settings file
"[path:/users/sandy081/work/vscode]": {
"settings": {
"editor.insertSpaces": false
}
},
"[uri:file:///users/sandy081/work/vscode]": {
"settings": {
"editor.insertSpaces": false
}
}- Only absolute paths are supported
- As of now only settings will be supported, but can be extended for other configurations too (launches, tasks & extensions)
- All containing folder settings are merged and closest folder wins. Opening a folder in VS Code and if user has customised sub folders under it using user folder settings, all those customisations to sub folders are applied.
UX (In Discussion)
- A folder drop down is shown for all user folders those are already customised and scoped to the given opened root folder.
API (In Discussion)
- Reading works without any changes
vscode.workspace.getConfiguration('editor', vscode.window.activeTextEditor.document.uri)- New inspect hierarchy and option to override at resource level. Requires opt in for inspecting and updating.
defaultValue
userValue
workspaceValue
workspaceFolderValue
workspaceFolderUserValue
resource {userValue, workspaceValue, workspaceFolderValue}
defaultLangugeValue
userLanguageValue
workspaceLanguageValue
workspaceFolderLanguageValue
resourceLanguage {userValue, workspaceValue, workspaceFolderValue}
So if I understand correctly, local workspace settings will not be parsed from settings.local.json-like files from project's .vscode directory, but only from general user settings file?
@akwodkiewicz It also surprised me (unpleasantly, as settings.local.json seems like an easier concept) but I think I get it now – the proposed design allows you to customize specific paths, not just workspaces, plus your own customizations can be synchronized between computers via Settings Sync, which would not be easily achievable with .local.json files.
BTW, about Sync, I think the assumption is that most people will exclude these customizations from the sync as for example my two computers use different folder layouts and the absolute paths would break. Is that right, @sandy081?
Chiming in to say that I'm not fond of the idea of a global settings file but it's better than nothing. It feels like an unexpected divergence of existing design.
So if I understand correctly, local workspace settings will not be parsed from settings.local.json-like files from project's .vscode directory, but only from general user settings file?
This was one of the proposals but it has couple of drawbacks that users have to ignore this which is an overhead and these settings can't be synced.
@borekb You are correct that the proposed design is more powerful that you can customise any folder. Also it can be extensible for syncing.
BTW, about Sync, I think the assumption is that most people will exclude these customizations from the sync as for example my two computers use different folder layouts and the absolute paths would break. Is that right, @sandy081?
By default path specific settings are ignored from syncing and uri specific settings will be synced. Going forward we would like to come up with an identity (uri) for a workspace folder which can be used for syncing folder related state. This identity can be defined by the corresponding scm extensions like git.
Thanks for sharing the design. @sandy081
- no local.settings.json
So if I understand correctly, local workspace settings will not be parsed from settings.local.json-like files from project's .vscode directory, but only from general user settings file?
This was one of the proposals but it has couple of drawbacks that users have to ignore this which is an overhead and these settings can't be synced.
having to add it to .gitignore is acceptable IMO. In fact, some folks would like to commit and push it to git. This is indeed true of some users of Peacock. Some like to commit their changes while others want to ignore them. Having the file in the project folder structure makes this their choice, which is IMO a vote for local.settings.json
not being able to sync is an issue. agreed
- Paths/Uri
Only absolute paths are supported
"[uri:file:///users/sandy081/work/vscode]": {
"settings": {
"editor.insertSpaces": false
}
}
...
Going forward we would like to come up with an identity (uri) for a workspace folder which can be used for syncing folder related state
Having this file exist somewhere in the project as an option would still be extremely helpful. Why? Because:
- it is easily findable in the editor as you are working
- can be associated with a project for a user (and gitignored if desired)
- can even be placed in th
/.vscodefolder if so desired
imagine this setting:
"[rel:${workspace}/.vscode/local.settingsjson]": { }If a full path is required, this would be a problem across machines as many of us have more than one.
The setting I listed here would effectively allow a local.settings.json file and choose to either gitignore or not
Here is an example of a .vscode/settings.json file after Peacock has changed colors for folks:
{
"workbench.colorCustomizations": {
"activityBar.background": "#ff511a",
"activityBar.activeBackground": "#ff511a",
"activityBar.activeBorder": "#00ff3d",
"activityBar.foreground": "#e7e7e7",
"activityBar.inactiveForeground": "#e7e7e799",
"activityBarBadge.background": "#00ff3d",
"activityBarBadge.foreground": "#15202b",
"titleBar.activeBackground": "#e63700",
"titleBar.inactiveBackground": "#e6370099",
"titleBar.activeForeground": "#e7e7e7",
"titleBar.inactiveForeground": "#e7e7e799",
"statusBar.background": "#e63700",
"statusBarItem.hoverBackground": "#ff511a",
"statusBar.foreground": "#e7e7e7",
"panel.border": "#ff511a",
"sideBar.border": "#ff511a",
"editorGroup.border": "#ff511a",
"statusBar.border": "#e63700",
"titleBar.border": "#e63700"
},
"peacock.color": "e63700",
}The idea here is that these colors are for this specific user in this specific project. SInce Peacock was created over a year ago, this has been done in the .vscode/settings.json much to many people's chagrin. Because it is in that file it has to either be gitignored to keep it local to a person or everyone on that project shares the same colors. There are users who want 1 or the other option. This is why I get excited about an option that allows a file in the same project.
Just wanted to provide some context for you :)
@johnpapa My understanding is that you could still commit .vscode/settings.json for project-wide settings but that now individuals can override those settings by adding them to their user settings with the proposed folder-specific settings. Doesn't that solve your example problem?
Maybe I misunderstand ... I read the above design as they are proposing a new file, and that file is referenced in user settings. But if you are saying that the settings themselves go in the user settings, that would be a huge huge huge set of settings. but I dont think that is what they are saying.
I read this design to mean that user settings would have a section that points to a file (of our choice) that hosts project specific local settings. this would only work if it could be used for a specific user on a specific project. Thats where Peacock users (660k installations) suffer today. Today, it is impossible to store settings for a user on a specific project, that apply the color customizations.
Maybe I dont understand the design that is being proposed. I would love to hear more so I can see how this might solve the problem.
@johnpapa I understood that it would be the content of the hypothetical settings.local.json that would be in the global user settings file. So the more projects you work on, the bigger your user settings become. And the path reference that you mention is a reference to a particular project where these overrides would be applied. Please correct me if I'm wrong though.
I also agree that having an ignored file inside each repository is much easier to manage. I understand that in this case the settings sync would not apply...
...but if I had a choice, then I'd rather have only my global settings synchronized. Because if I ever needed to access a project from a different machine then I would just push the settings.local.json to remote using a specific branch (e.g. vs-config/akwodkiewicz) since I have that file already in my local repo.
@johnpapa I understood that it would be the content of the hypothetical
settings.local.jsonthat would be in the global user settings file. So the more projects you work on, the bigger your user settings become. And the path reference that you mention is a reference to a particular project where these overrides would be applied. Please correct me if I'm wrong though.
if this is correct, then that could be a blocker for peacock. I have 100 projects, I certainly dont want a section in user settings for each one of those. I imagine not everyone would like that. @sandy081 - can you comment?
Firstly, thanks for posting here about the design, @sandy081. I do have my concerns though. Perhaps I'm missing something, but after reading the above, this does seem rather like a needlessly complex solution to a simple problem with a fairly obvious solution (i.e., settings.local.json or the ilk).
The issue over syncing is lost on me. This is a) not a feature I can envisage myself or many others using (perhaps others would though), but moreover b) there are other perfectly good approaches to use (that don't have the restriction of absolute paths). For example, you could link (hard or soft) the settings.local.json file in your repo/project to another location (in a repo or a directory that gets synced elsehow), thus allowing the simple and intuitive idea of a settings.local.json file whilst not creating an obstacle to syncing such files across computers.
having to add it to .gitignore is acceptable IMO. In fact, some folks would like to commit and push it to git. This is indeed true of some users of Peacock. Some like to commit their changes while others want to ignore them. Having the file in the project folder structure makes this their choice, which is IMO a vote for local.settings.json
This is even less of a problem when you consider you can use the .git/info/exclude file to locally exclude something in the repo (i.e., an ignore pattern that doesn't have to be added to the .gitignore, which is typically committed of course). This could also be done on a global basis for all repos, of course.
The proposed solution would allow me to use project specific settings without polluting the project working directory. This is exactly what I needed. Thanks! 😁
@sandy081 Will it also be possible to store launch settings this way?
@remcohaszing from Sandy's reply, yesterday:
- As of now only settings will be supported, but can be extended for other configurations too (launches, tasks & extensions)
[edit: added more context]
But earlier had written:
Any chance this will be more generic, like allowing local "launch.json" files as well?
Yes
My very simple use cases would also favour the simple approach around settings.local.json:
- peacock use (many thanks for this extremely useful extension @johnpapa)
- addition of search exclusions in a particular monorepo for the packages I'm interested in
I do appreciate the thoughts around "external" structures to hold these settings, but that's not how my mental modal works when it comes to file system content. If I have repo based settings configuration, I would imagine a file "nearby" to override. Having overrides go in the other direction (i.e. up the food-chain) is strange to me. I admittedly don't understand the need for syncing, but this is likely because my use cases are fairly narrow.
Very much appreciate the consideration and conversation.
Thanks for the feedback.
To be clear, the proposal is to inline folder specific settings in user settings file just like language specific settings.
Again, user-folder-settings.json file inside or outside the workspace folder option is discussed and it seems to be a simple solution but not effective due to the reasons below. Hence it was excluded.
- If contained inside workspace folder, user has to explicitly ignore this file always in every folder user customises. Chances of committing this file mistakenly are more. Has more overhead and requires more tooling.
- Not an extensible solution and has impact on performance. Say - I want to customise sub folders and gets applied when parent folder is opened?
- Not intentional to manage user settings (global and folders) in multiple files.
- Synchronising user folder settings will become hard
- Not consistent with language specific settings which are also overrides.
path/uri specific settings overcomes all above concerns and is aligned with already existing language specific settings design. This is more powerful feature that allows user to customise sub folders which can be applied automatically.
Eg: If user has customisations for folder a and folder a/a.1 then if opening folder a in VS Code then user customisations for a/a.1 are also applied for files and folders under a/a.1.
Considered that user settings file will get longer but is acceptable given above benefits. Also wanted to mitigate this drawback by providing UI to configure user folder settings as mentioned in the design. I expect, those who are using json editor for managing settings, are already organising the settings file manually and continue the same.
Please consider that we wanted to have a solution that is robust and extensible going forward instead of limiting to a particular use case or extension.
Thanks for explaining the details. I don’t see it as solving all problems, but i do see your points.
I would think that ignoring the file is local.settings.json) is a user choice. The big win with that structure is it is extremely familiar to ode users and adds minimal cognitive load. Local settings override workspace settings override user settings override default settings. I’m also not understanding how the problems you outline with local settings are any different than workspace vs user settings. I trust you all know more than I do of course. I’m not challenging you on this - just trying to explain why from my perspective I do not see the same thing y’all do. :)
The problem I foresee with adding more sections to user settings is any customization that people want to make to a specific workspace just for them. Will now require a new section in their user settings.json file. Imagine adding a section with 20 customizations , and doing this for 10 projects —- this would add 200 lines to user settings. This could grow rapidly into quite the large and difficult to read settings file. This applies to more than one extension. Size isn’t the only issue tho ... if that was the only drawback it might be workable. And maybe it is.
Question ...
I’m not clear on is what this might look like. I’m trying to follow the file and uri examples and maybe you can help clarify. Would the file or uri point to the folder where we open a project? These things change machine to machine - so maybe I am hearing you wrong.
Question ...
Would any setting added inside of these sections be read by Code? For example if I add workbench color customizations to a section (which is a specific project) will Code use those colors when that project is open?
Thanks so much for helping explain this topic. Many of us appreciate you and we are very excited to learn more!
If contained inside workspace folder, user has to explicitly ignore this file always in every folder user customises. Chances of committing this file mistakenly are more. Has more overhead and requires more tooling.
I don't think it should be a concern of VS Code of what users might accidentally commit in their repo... they could accidentally commit so many things, after all! Like I was saying, this is no big deal to add to a global or local ignore (it doesn't have to go in the .gitignore file).
Not an extensible solution and has impact on performance. Say - I want to customise sub folders and gets applied when parent folder is opened?
How would customising a subdir of a project even work? I mean, would the VS Code settings change as soon as the active file changed? That might be odd in many cases. Regardless, you could still allow settings.user.json in subdirs to override parent dirs, or allow relative paths in the root settings.user.json file.
Not intentional to manage user settings (global and folders) in multiple files.
"intentional"? Do you mean "convenient"? I don't get you here.
Synchronising user folder settings will become hard
Not at all, for the reason I mentioned in my previous post. I strongly doubt this is something most people care about anyway. There's also the issue of absolute paths getting broken when you synchronise across computers.
Not consistent with language specific settings which are also overrides.
Consistent in what way? They aren't using absolute paths, and the problem is by nature quite different. You can have overrides with the settings.user.json approach anyway.
All I really wanted was a .vscode/settings.dist.json file. I think the proposed solution is acceptable and allows me to do what I want.
I am a bit confused why config files isn't an acceptable solution though. VS Code already reads nested tsconfig files seemingly without issue for example.
I would think that ignoring the file is local.settings.json) is a user choice.
I would say that who ever uses this feature will ignore this file otherwise there is no need of this feature. This means we are going to add overhead to users using this feature which we do not intend.
I’m also not understanding how the problems you outline with local settings are any different than workspace vs user settings
I am sorry that I do not understand how current user/workspace settings will have these issues. Can you please explain?
This could grow rapidly into quite the large and difficult to read settings file. This applies to more than one extension. Size isn’t the only issue tho ... if that was the only drawback it might be workable
Yes, this is the only drawback of this approach. To mitigate this I said we will provide manageable UI that will show User settings and User folder settings as separate tabs. May be I might be missing something, can you please mention what are the other issues with this approach? I am happy to dig deeper and know the issues.
Question ...
I’m not clear on is what this might look like. I’m trying to follow the file and uri examples and maybe you can help clarify. Would the file or uri point to the folder where we open a project? These things change machine to machine - so maybe I am hearing you wrong.
Good question. Yes paths and Uris points to folders. Paths are machine specific but Uris are unique across. For example you can identify a GitHub repo using a GitHub URI which can be used here.
"[uri:https://github.com/microsoft/vscode]": {
"settings": {
"editor.insertSpaces": false
}
}
So path specific settings are not synced where as URI specific settings are synced
Question ...
Would any setting added inside of these sections be read by Code? For example if I add workbench color customizations to a section (which is a specific project) will Code use those colors when that project is open?
These settings are synchronised when you use this repository any where.
Yes, these settings are no special and are read and applied when you open the folder. In the above example, spaces are not inserted for all files under vscode repo when you open that repo. Same with colour customizations.
I don't think it should be a concern of VS Code of what users might accidentally commit in their repo... they could accidentally commit so many things, after all! Like I was saying, this is no big deal to add to a global or local ignore (it doesn't have to go in the .gitignore file).
It is of concern of VS Code that any feature we provide should not be redundant and does not add overheads and not easy to use. Again if it does not need to be ignored then this feature is redundant.
How would customising a subdir of a project even work? I mean, would the VS Code settings change as soon as the active file changed? That might be odd in many cases.
Please see this example:
Let's say there is a monolithic project with sub projects, for eg: vscode project within editor sub project and if you defined settings for root project and sub projects like below.
"[path:/users/sandy081/work/vscode]": {
"settings": {
"editor.insertSpaces": false
}
},
"[path:/users/sandy081/work/vscode/src/vs/editor]": {
"settings": {
"editor.insertSpaces": true
}
},When you open root project in vs code and above settings are applied to the files accordingly. Files under editor project will spaces inserted and whereas for other files in the project it does not. Not sure what is odd here, can you please explain may be I am missing something?
Regardless, you could still allow settings.user.json in subdirs to override parent dirs, or allow relative paths in the root settings.user.json file.
User can add settings.user.json in any subdir which adds more overhead for user: Ignore all of them. Also VS Code has to now scan all sub directories to load these files which is costly. Supporting relative paths in the root file adds more complexity and ambiguity. User has now more than one way to customise a folder. This is the reason local settings json file approach is not effective, not extensible and non performant.
"intentional"? Do you mean "convenient"? I don't get you here.
Yes I mean not convenient to manage user settings in multiple files.
Not at all, for the reason I mentioned in my previous post. I strongly doubt this is something most people care about anyway.
Of course they do. If I have some user settings for my GitHub repo I would definitely want these settings synchronised across my machines instead of manually copying it. For eg: take folder colour customisations from Peacock extension, if I configure them on one machine I would want the same in all machines for the give repo.
There's also the issue of absolute paths getting broken when you synchronise across computers.
Explained above how this will be supported.
Consistent in what way? They aren't using absolute paths, and the problem is by nature quite different.
Consistent in using semantics and overriding from user settings file.
I am a bit confused why config files isn't an acceptable solution though. VS Code already reads nested tsconfig files seemingly without issue for example.
Its typescript extension and not VS Code. User folder settings is core feature of VS Code and these two features are different. You want tsconfig files part of your project and share with the team but you do not want to share your user folder settings. Team project settings (shared) is already supported.
I'm not a fan of the absolute paths in a central location either. It's a
bit painful to maintain, IMO.
I completely agree and this is another pain point. We will be providing tools (commands) and UI for users to configure easily. For eg: there can be UI to select a folder and provide user customizations.
Can we make it so that we can import files in our user settings so that we
can separate out the overrides into different files if we want?
Good idea but as said it is not convenient for all to manage user settings spread across multiple files. These are user settings and shall be contained in one file.
I still don't get how this approach would solve one simple usecase which I suppose is quite common (unless further action on other parties):
I have a python project, which unfortunately stores the python path in settings.json. So this means I cannot add settings.json to vcs. Now I want to enforce some project specific settings to all users working on the same project. how would that work with the suggested approach?
to be honest, for me this whole concept seems a little bit over engineered (maybe I'm wrong, I don't know the internals). But I definitely would prefer a much simpler approach, which simply allows me to add one or more settings.{user,company,dist,whatever}.json files. These files get parsed alphabetically after settings.json and overwrite already specified settings.
this allows each project manager to add project specific settings, while have company specific settings separated from each other but all in the same vcs and the same .vscode folder and still keeps it simply and stupid so that everyone understand it....
Thank you Sandeep, great collection of points and their counter arguments 👍
I'm not a fan of the absolute paths in a central location either. It's a
bit painful to maintain, IMO.I completely agree and this is another pain point. We will be providing tools (commands) and UI for users to configure easily. For eg: there can be UI to select a folder and provide user customizations.
And another UI for a wizard, to dump any stalled absolute-paths, correct?
I don't think it should be a concern of VS Code of what users might accidentally commit ...
It is of concern of VS Code that any feature we provide should not be redundant and does not add overheads and not easy to use. Again if it does not need to be ignored then this feature is redundant.
I believe most developers do use and fully own our .gitignore files; it is a "user-settings" file, pre-dating VScode, that should be part of the mix. And indeed, a settings.user.json file should (and will) be always ignored.
But why does that fact render such a feature redundant?
Can we make it so that we can import files in our user settings so ...
Good idea but ... These are user settings and shall be contained in one file.
Why is a single user-settings file, in principal, better?
Why should all user-settings be contained in a single file with absolute paths, necessitating a UI & API to make it work?
(and not the "dumb" settings.user.json + ~/.gitignore alternative)?
Said that, i do roughly understand the shortcomings of the alternative you laid out 3 days ago, particularly its interaction with multiple projects in a singe workspace, but in principal, it is not an inferior solution, and neither forces overhead to users.
Plus, it does not require any UI or API to be workable, and wil readily intergate with home-made tooling & json-processing scripts, eg the simplest:
git clone https://... foo.git
ln -s ~/lib/vscode-settings.user.json ./foo.git/.vscode/settings.user.json
Not sure how good this idea is but want to throw it around:
If the VSCode team wants to insist on settings.json being the source of truth while also accommodating the community demand for settings.local.json, it could work like this:
"[uri:https://github.com/microsoft/vscode]": {
- "settings": {
- "editor.insertSpaces": false
- }
+ "settingsFile": "${workspaceRoot}/.vscode/settings.local.json"
}I can also imagine a "normal" setting like this:
{
"additionalSettingsFiles": [
"/my/local/settings.json",
"${workspaceRoot}/.vscode/settings.*.json"
]
}The main point here is that I think there could be a system where everything is explicit in the main settings.json file (I can see the benefits of that) while still allowing local settings.*.json files.
Honestly, the "all settings in one file" thing reminds me of the Windows Registry, which everyone knows is fantastic! :)
Visual Studio uses .user files for user settings.. just seems like such a simple paradigm. I truly think this is making things a lot more complicated to solve a problem that is REALLY minor.
Also, once we delete a folder, we're going to have dead settings in our user settings. This is another pain point to this approach.
But either way.. I'll be glad to have the functionality. I just think it would be super-simple to have a local settings file right next to the other settings
Visual Studio uses
.userfiles for user settings.. just seems like such a simple paradigm. I truly think this is making things a lot more complicated to solve a problem that is REALLY minor.
This a hundred times over. In my eyes the single file approach makes even less sense when it comes to other project specific files like launch.json. A launch.user.json or launch.local.json next to it feels like a much more expected behavior.
to be honest, for me this whole concept seems a little bit over engineered (maybe I'm wrong, I don't know the internals). But I definitely would prefer a much simpler approach, which simply allows me to add one or more
settings.{user,company,dist,whatever}.jsonfiles. These files get parsed alphabetically aftersettings.jsonand overwrite already specified settings.
Sigh... this is what I asked for 2.5 years ago in this thread. It seems so incredibly simple. A file, which we can gitignore, which supercedes another file which we don't gitignore. Done. User settings = user controlled, project settings = project controlled, users settings supercede project settings. Done.
I'm happy there will be some way to solve this problem, I suppose, but the simple, well-worn solution that's so common and easy is all that I think almost everyone really wanted...
Thanks for responding to my points.
It is of concern of VS Code that any feature we provide should not be redundant and does not add overheads and not easy to use. Again if it does not need to be ignored then this feature is redundant.
I honestly don't see how this proposed feature is redundant or difficult to use in the slightest. In fact, I don't even know how redundancy comes into this matter... maybe I misunderstood you. Regardless, I consider the simpler proposal (more or less the original one, with some nuances I described) to be both more intuitive and natural solution — as it seems do others here, though it's hard to speak objectively of such things. I'd also argue that if you're going against the design adopted by various other text editors and with a totally new one, there ought to be a very good reason indeed.
How would customising a subdir of a project even work? I mean, would the VS Code settings change as soon as the active file changed? That might be odd in many cases.
Please see this example:
Fair enough, though this could be done just as easily with relative paths in a settings.user.json file, or settings.user.json files within your workspace, like I mentioned before. (Point continued below.)
User can add
settings.user.jsonin any subdir which adds more overhead for user: Ignore all of them. Also VS Code has to now scan all sub directories to load these files which is costly. Supporting relative paths in the root file adds more complexity and ambiguity. User has now more than one way to customise a folder. This is the reason local settings json file approach is not effective, not extensible and non performant.
One would only have to support one solution or the other, not both. The solution with relative paths in the root (and only) settings.user.json is no more complex, no less performant, and definitely easier to manage than a central/global settings file. The other solution is no more complex either, and although a naive implementation (scanning subdirs) would be less efficient, a solution where settings examined upon opening a file/directory (plus cacheing) would seem just fine. But probably the first solution makes more sense, in any case.
"intentional"? Do you mean "convenient"? I don't get you here.
Yes I mean not convenient to manage user settings in multiple files.
On the contrary, I see it as far more convenient. I expect user settings for a project to be in the project directory, just not committed. And I know I'm not the only one here.
Of course they do. If I have some user settings for my GitHub repo I would definitely want these settings synchronised across my machines instead of manually copying it. For eg: take folder colour customisations from Peacock extension, if I configure them on one machine I would want the same in all machines for the give repo.
Well, I guess I mean I personally don't have a use for it, since I only work with one machine (at least on a given project), and I think that applies to a lot but certainly not all users. Irrespective of that, I think the proposed solution with symlinks and a central repo is more elegant since it does not enforce centralisation per se, and is less complex too.
Consistent in using semantics and overriding from user settings file.
I think this is a tenuous analogy. They're fundamentally very different, since one is about overriding parent directories, while the other is about overriding default settings for different languages. Conceptually no real similarities here except both involve overrides.
Anyway, I won't contend these issues further, because I suspect however much feedback is given, the design has already been decided on. I'll just finish by saying that although I'm not terribly happy with this apparently over-engineered solution, I am glad it exists rather than nothing! I appreciate your work on implementing this. :-)
I would say that who ever uses this feature will ignore this file otherwise there is no need of this feature. This means we are going to add overhead to users using this feature which we do not intend.
Many features have overhead to using them (even if it's just enabling them). Adding the pattern to your global gitignore is a one-time thing that I'd much prefer than having the settings completely disconnecting from the folder. I'd like my project folders to be portable.
Yes, this is the only drawback of this approach.
There are other drawbacks to this approach. For example if I rename my folder, my settings "disappear". If I copy/paste my project to try and strip it down to make a repro, it doesn't bring those settings with it - which might result in different behaviour and be confusing.
@DanTup that's a rather significant drawback.
- You can't share your local settings with a colleague (e.g. email);
- nor can you easily duplicate settings for sibling projects (you need UI for that, or delicate json-editing).
- You can't have certain local-settings applying to certain projects, maitained by symlinks, that pick-up any changes implicitly.
- You can't script project+settings creation from multiple repos, you have to rely on the new UI & API (we do that for multiple interdependent projects).
Thanks all for your opinions and they really help. Will go through them again and consolidate and reiterate.
User can add settings.user.json in any subdir which adds more overhead for user: Ignore all of them. Also VS Code has to now scan all sub directories to load these files which is costly.
My initial proposal was very simple: read settings.*.json in addition to settings.json, from ${workspaceRoot}/.vscode. I did not and do not expect VSCode to look in and subdirectories for settings files. This entirely circumvents the issue of scanning subdirectories.
My opinions about .gitignore changes have been expressed thoroughly by others, but I will point out that adding a single entry for /.vscode/settings.*.json is not at all onerous.
I do like the existing design, and it seems very powerful, but folder-specific settings stored in a global location is very intuitive to me and the reliance on absolute paths is a big downside. I'd rather not have my configuration break because I decided to reorganize or move my projects. I would love to have both, the current design as well as my original proposal.
Supporting relative paths in the root file adds more complexity and ambiguity.
Please add path overrides to workspaces (*.code-workspace) in such a way that I can specify an override using the workspace folder name instead of the full absolute path. Something like [folder:<name>/subdir]: { ... } or maybe [root:...] or [workspace:...]. This would solve many of the problems with absolute paths.
Thanks @sandy081, that's good to hear. Appreciate you being open-minded about this and engaging with all of us users!
@sandy081 taking a look into the recently announced Github Codespaces, I now see how your approach really makes sense when dealing with repository-bound configurations.
If I work locally on a Github repository, such as VSCode's, with the proposed solution, my synced settings.json would look like this:
"[uri:https://github.com/microsoft/vscode]": {
"settings": {
"editor.insertSpaces": false
}
}When I spin up a Codespace to work remotely or in another PC, all my custom configs for the project will be synced into the workspace, including Peacock's color scheme.
I didn't understand the use-case for syncing local workspace settings, but now it really makes sense and will come in handy once Codespaces becomes more widespread. Either way, I still find the solution a little confusing to the user, as the file with configs will be separated from the project folder.
This, of course, does not limit the syncing functionality to Github's platform, but applies to any cloud IDEs out there built on top of VSCode (StackBlitz, GitPod, code-server, etc.), assuming they put the effort in integrating with the synced settings.
If it makes sense with Codespaces, then I would suggest that is a problem Codespaces needs to gets right. In this example, Codespaces is effectively a stand-in for your machine.
So Codespaces might allow you to attach your local settings file (or even better just sync it directly from VSCode behind the scenes) and that's that. Your codespace would look the same as VSCode and everyone's happy. The Git repository would remain unaffected.
In a more general light, it would essentially be solving the problem of syncing VSCode settings from the desktop to Codespaces and that could really be an "under-the-hood" integration between VSCode and Codespaces.
But from a development team perspective however, another team member who uses VSCode shouldn't have my settings being synced to their codespace or their machine and vice-versa.
Let me throw in my use case.
I run my python unittest parallely using pytest-xdist. On my machine where I have 16 cores I wanted to have high degree of parallelism. I cannot have machine wide setting for this as it is really a project specific.
"python.testing.pytestArgs": [
"${workspaceFolder}/tests",
"-n 6",
"--cov-report=xml:${workspaceFolder}/coverage.xml",
"--cov=${workspaceFolder}/app",
],And when I use remote container or a low spec cloud VM I want my parallelism degree to be lower plus probably turn off coverage.
"python.testing.pytestArgs": [
"${workspaceFolder}/tests",
"-n 2",
],Currently every time I switch I have to make changes in .vscode/settings.json, its annoying
Something that has been on my mind is having the ability to choose multiple workspace settings, or "profiles" for lack of a better term. Said profiles can be available anywhere, and you could freely turn on or off any profile to add or remove your pre-setup functionality and configs for different use cases.
For example, one profile would be the default/global profile. For me that would include extensions that integrate with git, colour themes, and other visual tweaks - stuff that is not project/language specific.
A second profile could be for Python development. It includes the Python extension, and other possible python-related extensions.
A third profile could be for C++, which includes, you guessed it, extensions and config for C++.
What would benefit users the most, is having the ability to select multiple "profiles";
If a project uses Python, you use your default profile and the Python profile.
If a project uses C++, you use your default profile and the C++ profile.
If a project uses both Python and C++, you can enable all three profiles.
You nailed it. I've been thinking about the same concept for awhile. I really want to have a significantly different set of extensions and configuration for different types of projects. Gradle/Kotlin/Java needs a very different setup from NPM/Node.js/React but I develop with both frequently.
You nailed it. I've been thinking about the same concept for awhile. I really want to have a significantly different set of extensions and configuration for different types of projects. Gradle/Kotlin/Java needs a very different setup from NPM/Node.js/React but I develop with both frequently.
At least as long as you don't have a Gradle/Kotlin/Java/NPM/Node.js/React project, it's pretty easy to start distinct (unrelated) VS Code profiles with shortcuts [as a workaround, of course].
Our team also needs the ability to locally override shared folder settings. Scenario: some settings are good for almost everyone and every platform and situation, except for some single specific case.
If you don't mind my asking, what's progress on this been lately? :-)
My initial proposal was very simple: read
settings.*.jsonin addition tosettings.json, from${workspaceRoot}/.vscode. I did not and do not expect VSCode to look in and subdirectories for settings files. This entirely circumvents the issue of scanning subdirectories.My opinions about
.gitignorechanges have been expressed thoroughly by others, but I will point out that adding a single entry for/.vscode/settings.*.jsonis not at all onerous.
This proposal is simple and very good. Why isn't it done already?
It is taking years to do such a simple thing, this is plain bullshit.
Aren't there already user settings in ~? Why not just add the ability to target specific workspaces or folders for setting overrides here, at least in the short-term? No muss, no fuss. You don't even need to change the UI except to add some convenience shortcuts to create an override.
A generic "include" syntax would work similarly with a bit more work (you have to think about the target file for editing in the UI a bit more).
A suggestion for those butting their heads against this design flaw: template your settings with a devops script instead of committing them directly to the repo.
My use case: settings as a dependency which my team can work on together, easily pull into an arbitrary project, and track with the project as part of our efforts to automate standards across collaborators.
This doesn't strictly fall into the OP's .vscode/<somefile> suggestion —the target file would live in the distribution method's default location (think ./<submodule>/…, or node_modules/<package>/dist/…) but this ticket seems to be the best fit.
@olets I have similar needs. When you need the same settings on multiple projects, and in all cases you want them also in source control.
How is this still not a thing yet?
I'd really wish if it would be possible to compose settings files by merging settings from another file.
This comment is related to #59374 and #15909. This would permit to solve different kinds of problems, including the current one without needing to add an additional layer of settings file (beyond workspace and folder settings). It also makes it possible to group settings by functionnality in a similar fashion as the gitignore templates (this is an application of the single responsibility principle).
To resolve the current situation, for example, I would have shared workspace settings being tracked in the .vscode folder. I would keep my untracked workspace settings in file .git/vscode/settings.json which would look like:
{
"clangd-arguments": [
"--all-scopes-completion=0",
"--completion-style=detailed",
"--pch-storage=memory",
"--header-insertion=iwyu,
"-j=32"
]
// ... other untraked workspace settings
}Then the tracked workspace would declare the "--compile-commands-dir=." . .vscode/settings.json :
{
"settings.merge": {
"filePath": "../.git/.vscode/settings.json", // absolute or relative to the current file
"precedence": "applyAfter", // "applyAfter": settings form the included file have precedence
"defaultMergeStrategy": "append", // "append": if an incoming key exist in the current file and both are objets or
// both are arrays, then append the key:value pairs or values resp.
},
"editor.insertSpaces": true,
"editor.tabSize": 4,
"clangd.arguments": [
"--compile-commands-dir=." // or ${workspaceFolder}: clangd is always started in the root of the workspace
]
}To make things shorter, the "precedence" key could default to "applyAfter" and the "defaultMergeStrategy" could default to "append": this is pretty much how the settings in user, machine, workspace files are merged.
The only drawback of this technique is that the shared workspace settings needs to expose the "settings.merge" customization point.
This is related to #128226, but they are not duplicates. It would be nice if both #40233 and #128226 existed at the same time.
- #128226 gives users the ability to ignore default settings
- #40233 gives users the ability to use-but-override default settings
Sorry for the duplicate comment, but I figured it would be nice to have the same comment on both issues...
Excellent suggestion! If I may, I'd like to expand on it:
Rather than three files, I'd have all four combinations:
- User
settings.json - User
settings.local.json - Workspace
settings.json - Workspace
settings.local.json
This would be very useful to those of us who keep their user settings in Git. There are certain changes (like the infamous "window.zoomLevel": 1) that I never intend to commit and always have to revert by hand. Having private overrides at the user level would solve that.
First I just want to thank the VS Code team for all their hard work building such an amazing product, and I'd love to see the features requested in this discussion incorporated natively into the product.
However, the absence of these capabilities has been problematic for long enough with the teams I work with that we opted to finally make an extension that allows us to use shared+local config files in the way we needed, and figured I'd share on the off chance it's helpful for anyone else.
https://marketplace.visualstudio.com/items?itemName=swellaby.workspace-config-plus
There's a few other extensions that offer some similar capabilities as those discussed on the thread with different implementations/features:
https://marketplace.visualstudio.com/items?itemName=williamtfligor.settings-extender
https://marketplace.visualstudio.com/items?itemName=raymcclain.project-settings
https://marketplace.visualstudio.com/items?itemName=dangmai.workspace-default-settings
None of these extensions provide every single item requested throughout this thread, but hopefully one or more can help bridge the gap for some folks in the interim until VS Code provides some kind of native support.
Another similar extension, more mature than those listed, with loads of features. Been using it for a while and it's good: https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.global-config
Another option could be to allow using a workspace name in User/settings.json file
"[my-project-name]" : {
"workbench.colorCustomizations": {
"statusBar.background": "#380f17",
"statusBar.foreground": "#e7e7e7",
},
},
I wonder how this would affect my proposal for a better settings editor #136068? I didn't consider multi root workspaces so that already requires some adaptation. I do believe that if you are adding more locations for settings then something like my proposal is even more necessary.
#39272 is also related to having vscode properly configured for a given workspace.
While dealing with interaction between user settings and workspace settings today I had an idea about how settings could be partitioned.
Typically user settings are just for general use. I customize how vscode looks and feels. I personalize it in user settings.
In workspace settings that get checked in to git I only want code/tool related settings. For example: spaces per tab, autopep8, etc. These are the settings to make sure the project works the same for everyone.
(Note: I am a big fan of putting all tool settings in their own config files instead of vscode settings. Automated processes for build, pre-commit, etc. won't be using vscode to run those tools.)
It seems like the above is trying to separate out workspace settings that are user specific vs project specific in multiple files in the workspace. That might help.
Even better, would be to actually categorize settings by intent. Is it
- user customization of how vscode works,
- workspace settings that make things work correctly for all developers
- some other kind of settings
It is certainly clear that settings are complex and having multiple levels without a clear indication of the actual settings values being used in the workspace is very problematic. I really would like to see an interface that clearly showed what is being used. #347 talks about this
Also, as long as some settings don't show in the editor window, but require editing the javascript directly it would be helpful if just below the selection for user/workspace there were buttons to open the appropriate file. The workspace file is pretty easy to find in the directory navigation pane, but user settings are a pain to open manually.
This is my most desired feature. I code in many different environments and machines. I don't to jump through the hoop of making a workspace just to workaround this issue.