Allow storing settings outside of working directory

[remcohaszing]

I use git for version control. I regularly type git clean -xdf from muscle memory, so I can work in a pristine environment, for example when switching branches.

Often I totally forget about my .vscode directory, so I will need to restore them manually. Of course it is possible to use workspaces instead, but it’s so convenient to just use code . from the terminal. It would be a shame to give this up.

My idea is to offer a different location for these configurations, which will be loaded when a directory is loaded, like .vscode, but outside of the version control.

Some potential locations:

• .git/vscode
• $XDG_CONFIG_HOME/Code/Projects/${dirname}

[joaomoreno]

Why don't you check in the .vscode to your repository? Or set the settings in your user settings file?

[remcohaszing]

Editor specific files don’t belong in version control. A code base should be editor agnostic.

Some settings might be related to just one project, such as debugging configurations.

[joaomoreno]

You seem to be in a pickle then, don't know anyone else struggling with this issue. I suggest putting the settings somewhere in your code and make a bash alias/script which simply symlinks it to $PWD/.vscode/settings.json, so you can always restore them after git clean.

[remcohaszing]

I have seen plenty of pull requests of people adding unwanted editor related files. Sometimes these get accepted, cluttering the code base, other times they get rejected. This is not just a VSCode issue, but by storing editor settings in the project root, VSCode has become part of the problem.

For example, I think the majority of the VSCode team wouldn’t be fond of a pull request which adds for example.project, .idea, .tern-config, or package-lock.json to the repository (or gitignore).

Despite the fact that I use and like VSCode, .vscode is no different from those files.

[joaomoreno]

@bpasero Do we have a dupe of this?

[bpasero]

@sandy081 might know. The best is to create a workspace file and store settings in there.

[sandy081]

#40233

[remcohaszing]

@bpasero Creating a workspace file is a workaround, but that does mean one would need to run code path/to/workspace.code-workspace instead of code path/to/project, which in practice is as simple as code . 99% of the time.

A solution could be to resolve a matching workspace file when code path/to/project, although that might cause other issues when this behaviour is undesired.

@sandy081 This is not a duplicate of #40233.

That issue is about committing partial VSCode configuration.

This issue is about moving project configuration outside of the git tracked files.

Actually, the solution from the other issue still suffers from the problem described in this issue.

[joaomoreno]

@remcohaszing Please read #40233 once again. I believe this is exactly what you are looking for.

[sandy081]

@remcohaszing Using workspace is a workaround to avoid sharable workspace settings. But #40233 is meant to support non sharable workspace settings.

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!