firelizzard18 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Currently .vscode/settings.json is shared as it is part of .vscode folder. So it cannot be treated as non shareable one

borekb commented 6 years ago

Related issue with some additional use cases: Local settings overrides (settings.local.json) #37519

segevfiner commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@remcohaszing I believe you meant #56148

remcohaszing commented 5 years ago

Yes, sorry, my bad.

firelizzard18 commented 5 years ago

I created #59374 to expand on my suggestion for your use case, since your issue was closed.

jamietre commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

redders6600 commented 5 years ago

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

johnpapa commented 5 years ago

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.

Github repo

extension in marketplace

tommck commented 5 years ago

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)

runofthemillgeek commented 5 years ago

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.

ghost commented 5 years ago

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.

ThadHouse commented 5 years ago

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.

tommck commented 5 years ago

Aren't we just asking to mirror what Visual Studio does with the ".user" files? It seems pretty logical to me

jamietre commented 5 years ago

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.

coldino commented 5 years ago

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.

hng0 commented 4 years ago

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.

ankostis commented 4 years ago

(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?

sandy081 commented 4 years ago

There is some complexity with UI and API otherwise it is easy to implement.

ankostis commented 4 years ago

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

tommck commented 4 years ago

There is some complexity with UI and API otherwise it is easy to implement.

"Aside from it being complex, it's easy" 😂

alexreg commented 4 years ago

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

gjsjohnmurray commented 4 years ago

@alexreg see #92242 for details. The milestone indicates work being done during March, and expected to ship in early April.

johnpapa commented 4 years ago

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.

alexreg commented 4 years ago

@gjsjohnmurray Thanks; very glad to know!

sandy081 commented 4 years ago

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.

tommck commented 4 years ago

@sandy081 Any chance this will be more generic, like allowing local "launch.json" files as well?

sandy081 commented 4 years ago

Any chance this will be more generic, like allowing local "launch.json" files as well?

Yes

sandy081 commented 4 years ago

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}

akwodkiewicz commented 4 years ago

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?

borekb commented 4 years ago

@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?

mg-christian-axelsson commented 4 years ago

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.

sandy081 commented 4 years ago

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.

tommck commented 4 years ago

"closest folder"?

So the local settings don't actually override what's in settings.json?

On Thu, Apr 9, 2020, 6:51 AM Sandeep Somavarapu notifications@github.com wrote:

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 https://github.com/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 https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/40233#issuecomment-611463841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHPXRKC4GGYDBWM3WHGUWDRLWSDBANCNFSM4EIK7FYQ .

johnpapa commented 4 years ago

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/.vscode folder 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 :)

garretmh commented 4 years ago

@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?

microsoft / vscode

[Feature] Local Workspace settings #40233

Design

Introduce Path / Resource specific configuration in User Settings

UX (In Discussion)

API (In Discussion)