You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if workspace level settings could be split into two separate .json files, one which is intended to be checked into source control and shared with the team, and one that is intended not to be shared and ignored from source control.
Use Case:
In my particular case, we are using the Perforce for VS Code plugin, which requires several settings to be set in order to find and login to the Perforce server. These settings obviously should not be shared across the team as everybody will have different values. I could theoretically store these settings in my user settings (or system environment variables), but those are global across all VS Code instances and unfortunately we have different server settings for different projects, so I would have to constantly go into my user settings and change them every time I switch projects.
At the same time there are definitely some settings that I want to share across all members of my team: typescript.tsdk for example, ensuring that every team member is using the typescript version that is pulled down from npm.
I know this use case is rather specific to my particular situation, but I have to believe that it is a fairly general and common scenario.
Suggestion:
Add the ability to create a settings.user.json file under the .vscode directory that is intended to be ignored in source control. In the case of conflict, the values set in settings.user.json would override the shared values in the settings.json file.
This is similar to Issue #851 however I don't see why the non-shared workspace settings need to be stored outside the workspace.
The text was updated successfully, but these errors were encountered:
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
I have the same request and @sandy081 the suggestion you provide does not work in the case were the team wants to have both a multi-root project and a combination of shared/private settings.
I would propose the following settings hierarchy default settings -> global user settings -> shared multi-root settings -> user multi-root settings -> shared folder settings -> user folder settings (user folder settings trump all others)
It would be nice if workspace level settings could be split into two separate .json files, one which is intended to be checked into source control and shared with the team, and one that is intended not to be shared and ignored from source control.
Use Case:
In my particular case, we are using the Perforce for VS Code plugin, which requires several settings to be set in order to find and login to the Perforce server. These settings obviously should not be shared across the team as everybody will have different values. I could theoretically store these settings in my user settings (or system environment variables), but those are global across all VS Code instances and unfortunately we have different server settings for different projects, so I would have to constantly go into my user settings and change them every time I switch projects.
At the same time there are definitely some settings that I want to share across all members of my team:
typescript.tsdk
for example, ensuring that every team member is using the typescript version that is pulled down from npm.I know this use case is rather specific to my particular situation, but I have to believe that it is a fairly general and common scenario.
Suggestion:
Add the ability to create a
settings.user.json
file under the.vscode
directory that is intended to be ignored in source control. In the case of conflict, the values set insettings.user.json
would override the shared values in thesettings.json
file.This is similar to Issue #851 however I don't see why the non-shared workspace settings need to be stored outside the workspace.
The text was updated successfully, but these errors were encountered: