616

Is the .vscode folder meant to be committed to source control?

In a fresh project, the folder is empty, except the settings.json file. What kind of things would go into this folder? Is it machine-specific, developer-specific like the .vs folder and thus not be committed? Or should all developers share this folder and thus it should be committed?

The comment at the top of the file .vscode/settings.json states:

// Place your settings in this file to overwrite default and user settings.
{
}

This seems to imply that the folder should contain project-specific settings and thus be included in source. Also, this post on UserVoice seems to imply some typings would go in there, also suggesting that it should be committed.

Ronald Zarīts
  • 11,819
  • 8
  • 39
  • 42
  • If you start a project in Visual Studio and then commit it there should be a proper (at least typical) start .gitignore FE. If it's meant to be there it probably will be. You can also reference [this](https://github.com/github/gitignore/blob/master/VisualStudio.gitignore) which I've used without issue. – ChiefTwoPencils Oct 06 '15 at 08:18
  • 5
    A good idea, @ChiefTwoPencils! For the record, the default `.gitignore` that Visual Studio creates does have `.vscode` folder excluded at this point in time. But since VS Code is itself rather new, they might have not gotten around to it yet. I've left the folder untracked for now while I get more info on it. – Ronald Zarīts Oct 06 '15 at 08:27
  • 1
    If you're reading this, subscribe to https://github.com/microsoft/vscode/issues/15909 and maybe one day you'll be happy – NikT Feb 03 '22 at 18:20

9 Answers9

533

Check in the .vscode folder if you want to share settings, task configuration and debug configuration with the team. I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team. We in the VS Code team share debug and task specific settings as well because we want our team to have the same set of debug targets and task targets for VS Code.

Btw you do not need to have a .vscode folder in your project for settings. You can also configure settings on a user level.

Darryl Hein
  • 142,451
  • 95
  • 218
  • 261
Benjamin Pasero
  • 113,622
  • 14
  • 75
  • 54
  • 195
    If you want to share file-level settings like "whitespace vs. tabs" then you should look at a cross-editor solution like [EditorConfig](http://editorconfig.org/) instead. – Tanz87 Oct 07 '16 at 02:40
  • 4
    This directory has a subdirectory "chrome" of 80 MB size. Are you sure this should be committed to the repository? – ygoe Jun 01 '17 at 08:50
  • Typically this folder does not contain a lot of data but it maybe that you are using an extension that adds more data there? – Benjamin Pasero Jun 01 '17 at 15:32
  • Is there any reason git would not be able to see the .vscode folder? – Robert Mennell Aug 23 '17 at 22:10
  • 29
    You must not be using VSCode for something like a python project where the workspace settings are going to have environment specific python paths for things like VirtualEnv or Anaconda environments. Checking these files in sounds like a huge problem for most scenarios. Check in a sample/default file instead. – StefanGordon Mar 27 '18 at 18:14
  • 3
    Followup on `symbols.json`: https://stackoverflow.com/questions/51876769/should-you-commit-vscode-symbols-file-to-source-control – ripper234 Aug 16 '18 at 12:11
  • 16
    So, this popular answer seems to be just wrong/incomplete. – ripper234 Aug 17 '18 at 13:02
  • 7
    Doesn't this limit developers choice of IDE? – Shadab Faiz Nov 30 '18 at 08:15
  • 1
    It makes sense to commit some settings but not others (like python environment paths). It would be nice if there was a way to split your settings accordingly. – Christopher Barber May 06 '19 at 23:33
  • 1
    @ChristopherBarber I was thinking the same, might seem odd but I wouldn't mind being able to set a different theme per project so I can quickly switch windows/VS Code instances and associate one theme with a specific project - But if I put it in project level settings it will enforce it to all users who access the project - It would be good if there was a settings.user.json that was also read and overrides the folder/workspace settings.json and you could just exclude the .user version – Dan Harris May 15 '19 at 13:10
  • Thanks. This makes good sense and keeps the team on the same page. – mkubal Mar 18 '20 at 15:25
  • 4
    I would like to check in some settings, such as `files.exclude` but not others such as `python.pythonPath`. Because the latter depends on the machine. Is there a way to check in some settings per-project? same code different users, different machines, and different OSes – dashesy Mar 31 '20 at 22:51
  • 1
    This is the most non-answer I ever read. – theKid Oct 19 '21 at 23:39
  • This makes sense if you use something like GitPod as well, as it will enable settings like enforcing eslint so the team doesn't have to do it manually each time they spawn a new GitPod instance. – Mark Lopez Apr 13 '22 at 04:16
  • 1
    The user setting I **need** at the workspace level is the theme, and I shouldn't need to impose my theme globally. Even if I didn't mind forcing everyone to use my theme, I don't want to be forced to having only one theme for that repo. I frequently have multiple worktrees, and therefore multiple workspaces for the same repo, all open in code at once. The theme is the easiest way to associate instance to worktree. I should have a `settings.user.*`.json` in the workspace that I can `.gitignore` or not without interfering with project settings. – Mike Apr 14 '22 at 23:58
222

Commit some files in .vscode folder

Recommendation is to generally exclude .vscode folder, but leave select JSON files that allow other developers to receive shared settings. If included, these settings will be enforced at the folder level (they are set whenever a commit is checked out).

Examples of settings to include:

  • Language specific test configurations to run the test suite(s) (settings.json)
  • Extension settings for linters and code formatting tools to enforce the language rules used in this repo (settings.json)
  • Run and debug configurations (launch.json)
  • Shared tasks - if managed with VS Code (tasks.json)

Note that some settings can be stored in the user settings or workspace file, or transferred to it from the .vscode folder. See below.

Sample .gitignore code

Here are the settings, as suggested at https://gitignore.io. You can search for "VisualStudioCode" there to get the latest recommended .gitignore file. I use this website as a starting point for .gitignore for most of my new repos:

# Created by https://www.gitignore.io/api/visualstudiocode
# Edit at https://www.gitignore.io/?templates=visualstudiocode

### VisualStudioCode ###
.vscode/*      # Maybe .vscode/**/* instead - see comments
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### VisualStudioCode Patch ###
# Ignore all local history of files
**/.history

# End of https://www.gitignore.io/api/visualstudiocode

In the above .gitignore file, the .vscode/* line (note: some debate on whether the * should be included - see comments; .vscode/**/* may be better to ignore nested folders as well) says to exclude everything in the .vscode folder, but then the !.vscode/a_specific_file lines tell git to "not" ignore some specific files in that folder (settings.json, launch.json, etc.). The end result is that everything is excluded in the .vscode folder except for the files specifically named in one of those other lines.

Other Factors

Including the .vscode folder in your repo doesn't actually hurt anyone that uses a different IDE (or text/code editor).

However, it may cause issues for other people using VS Code, or some of the settings may not load properly, if these files include generic settings that require something specific to your environment - like the absolute path the repo is installed in. The key is to avoid saving settings that are custom to your local environment, only sharing those that can (or, in the case of this repo, should) be used by everyone.

For example, if IDE setting files have absolute paths to the repo or any files/libraries, etc., then that is bad, don't share. But if all the references are relative, then they should work for anyone using the repo (although, be careful about path specification differences between Windows/Unix..).

About User, Workspace, and Folder settings

Note: the settings files in the .vscode folder are generally updated when you make changes to the folder version of the settings - but this appears to depend on how individual extensions are coded, because I've run across multiple exceptions to this rule.

  • If you make changes to the user settings, they are usually stored elsewhere (location depends on OS settings, usually in a home directory).
  • If you make changes to the workspace settings, they are usually stored in the *.code-workspace file that you are currently using. If you don't have a workspace (you directly opened a folder instead), then they will likely go to the .vscode folder, but, overall, this may depend on the extension that owns the setting anyway.

So, you should generally put custom settings for your personal PC into the user settings, and put generic settings into the workspace or folder settings.

LightCC
  • 9,804
  • 5
  • 52
  • 92
  • 3
    Better to do: !.vscode/settings.json.default Then mv settings.json to settings.json.default – JohnFlux Jul 29 '20 at 23:57
  • Yeah, that is another option. You can save a default/common version to the repo, then have people make a local version that they use after that point. It's hard to coordinate any changes that need to happen after that point forward, though. – LightCC Jul 30 '20 at 02:02
  • 3
    the `.vscode/*` does not work for me, had adjusted to `.vscode/` – oleksa Feb 05 '21 at 10:37
  • 4
    Changing to `.vscode/` will generally undermine the re-included files - `.vscode/*` will ignore all files (but _not_ subfolders). `.vscode/` will ignore the entire folder, which also means git will ignore the re-inclusions. Or as the documentation puts it: _It is not possible to re-include a file if a parent directory of that file is excluded._ – JimmiTh May 16 '21 at 00:07
  • Regarding the `.vscode/` or `.vscode/*` comments, there may be an alternate solution by using `.vscode/**/*`. I haven't tested yet, but it should effectively do the same thing as `.vscode/`, and include all folders and files recursively, but not have the side effect of disallowing the exclusions. – LightCC Jun 03 '21 at 17:43
  • 1
    By the looks of it, the majority of people here are really looking for: https://github.com/microsoft/vscode/issues/15909 (which hasn't been worked on). – NikT Feb 03 '22 at 18:18
  • @JimmiTh I don't think "`.vscode/*` will ignore all files (but not subfolders)" is true. I tried `.vscode/*` with `!.vscode/settings.json` and it ignored files in subdirectories of `.vscode` just fine. – bmitc Aug 08 '22 at 21:31
72

Between commit/ignore there is third clever option: commit with .default suffix.

For example you can add settings.json to .gitignore, and commit settings.json.default, much like it is common practice (in my team) with .env files.

I took this advice from video Commit editor settings to version control? by Mattias Petter Johansson

Tymek
  • 3,000
  • 1
  • 25
  • 46
  • 8
    A `settings.json.default` makes sense but this is assuming your entire team is using vs code and your codebase is not being shared to a wider audience. I find that my open source projects on GitHub, I just make sure I add it to my default gitignore, because I don't want to force a particular IDE on my potential users of my codebase. – james-see Sep 02 '18 at 19:36
  • 17
    @jamescampbell Adding IDE-specific files almost never forces that IDE on anyone - it just gives them the option to get your common environment settings if they do happen to use that IDE. The bigger quesiton is whether those files are officially supported - i.e. intended to always be up-to-date and working. Theoretically you could have multiple IDE environment files for different IDEs all present without any conflicts. – LightCC May 13 '20 at 19:55
  • I don't understand, do you put `settings.json.default` into `.vocode`? Then put team settings in it? Does VSCode respect the content in it? It's not even a json file. – Quuxuu Aug 16 '20 at 22:11
  • 1
    @Quuxuu you put .default in .vscode. VSC doesn't recognize it. `settings.json` is in gitignore, so if team member wants to use the defaults - just copy `settings.json.default` to `settings.json` (new file, ignored by git). This way you can override it with your own personal preferences later without commiting changes. – Tymek Aug 17 '20 at 16:21
  • 1
    @LightCC It is still bad practice to leave IDE specific folders in open source projects. Sure it gives them the option to use my environment settings, but chances are they already have their own environment set up. It is best to keep it as agnostic as possible unless the project **requires** a specific IDE (plugins, etc.), even then I would probably .gitignore it. If anyone wants the IDE settings, they can always ask. The exception would be within a company for standardization purposes. – jon.bray.eth Oct 29 '20 at 01:28
  • 4
    @SentientFlesh I disagree that it is "bad practice". This is more a convention that a given team or project needs to decide. Per my prior comment, what is the harm? Also, it's more about whether a toolset is "officially supported" by the core dev team/maintainer. – LightCC Oct 29 '20 at 15:11
  • @LightCC You're right, "bad practice" probably isn't the best term. Agreed that it's not harming anything. I generally exclude it from my commits, but I have found it helpful when I'm working on a project in a new IDE. This id definitely a per-case basis. – jon.bray.eth Nov 02 '20 at 01:52
  • This is a good compromise to provide default settings, launch configurations, etc, without having these files constantly being changed as different developers apply their own personal preferences to their own workspace. – Chris Bain Sep 19 '21 at 17:19
  • it's helpful when you (or someone else) need to pick up a project and dont have all the old debug, test, shell, maven, pytest settings that took days to tweak. – jpmorris Jun 27 '22 at 20:44
  • The problem with committing a `foo.default` file then excluding the actual `foo` from source control is that the default version *will* drift over time -- you'll add something to the real file or make a significant update, then someone will check out the project, copy over the default, and wonder why it doesn't work. I came here hoping to find a different convention. – Coderer Mar 03 '23 at 13:46
28
  • never commit .vscode/settings.json - with the weird exception of search.exclude . If you really need to, be very careful of putting only settings particular of your project that you want to enforce to other developers.
  • for validation, formatting, compilation use other files like package.json, .eslint, tsconfig.json, etc
  • The only .vscode that makes sense to include are complex launch configs for debugging.
  • Be careful, there could be a third party extension in your system that could put private information there !

What you can't do is copy & paste the whole settings.json contents file to .vscode/settings.json. I'm seeing some people doing this and committing the file is an atrocity. In that case you will not only break others workspace but worst, you will be enforcing settings to users that you shouldn't like aesthetics, UI, experience. You probably will break their environments because some are very system dependent. Imagine I have vision problems so my editor.* user settings are personalize and when I open your project the visuals change...

Summary: If you are serious don't commit .vscode/settings.json. In general, settings that could be useful for a particular project like validation, compilation, makes sense but in general you can use particular tools configuration files like .eslint, tsconfig.json, .gitignore, package.json. etc. I guess vscode authors just added the file for simplifying newcomer experience but if you want to be serious don't!

cancerbero
  • 6,799
  • 1
  • 32
  • 24
  • 11
    I feel your suggestion about `.vscode/settings` is too restrictive. Use `.eslint` or `.editorconfig` files if you can, but you should still check in `.vscode/settings` if you really do want a setting to be shared among all developers on a team/project – Matt Bierner Dec 06 '17 at 19:31
  • 4
    Matt, why do you assume that all other developers use vscode ? Could be people using webstorm, vim, sublime, that's why you should work with eslint, etc and not settings.json. – cancerbero Dec 06 '17 at 21:34
  • 5
    Again, checking in `.vscode/settings` make sense if your working on a team that uses vscode or you are working on a project where many developers use vscode. Not all of these settings have cross-editor equivalents – Matt Bierner Dec 06 '17 at 21:40
  • @MattBierner fair enough, if you are developing close source projects in a company that enforce the editor, but I don't think that's a common situation and specially in open source projects... – cancerbero Oct 25 '18 at 02:44
  • The point about third party extensions is very valid - As an example I believe the MS SQL Extension will add connection profiles to the project/workspace settings.json if it exists - Although it doesn't store credentials it may be checking in server names etc. – Dan Harris May 15 '19 at 13:15
  • What other IDE's are reading from a `.vscode` folder? That's crazy. If you're running an opensource project, you should be including configs for any editor possible (and you should have your contributors add configs for their IDE, that match the project style-guide, whenever possible). At a minimum I would suggest a config for pycharm and vscode. – DylanYoung Feb 11 '20 at 19:30
  • Good stuff. A sql extension was revealing my password in .vscode/settings.json – Isaac Pak May 16 '20 at 16:03
  • Worth noting that `dotnet new gitignore` DOES include .vscode/settings.json for tracking (among a few other files in .vscode/), so your suggestion to "never commit .vscode/settings.json" directly contradicts the MS blessed way of doing it. – Luke Jan 25 '21 at 18:54
  • Just as a specific counterexample: I had to commit `settings.json` because the Editorconfig extension for Code still does not support enforcing the `quote_style` property, and punts to setting the relevant properties declarations. You can have the linter enforce this, but autocomplete will still default to the wrong quotes so you wind up with a flag every time you use a suggested import. – Coderer Mar 03 '23 at 13:51
23

Why not just looking at the practice, other than the arguments around here?

One of the biggest project that keeps .vscode I found so far is Mozilla Firefox. It looks like the Firefox team shares their common tasks and recommended extensions.

So I guess it is not a bad idea to keep .vscode, as long as you know what you are doing.

I will update this post when I see other big projects that shares .vscode.

Bumsik Kim
  • 5,853
  • 3
  • 23
  • 39
  • 1
    We shouldn't do something just because a random great company uses that. – Naser Mirzaei Oct 07 '22 at 15:53
  • 4
    @NaserMirzaei True, and I did not say we should adopt it. But many random people say "no" here whereas it's not in practice in some organizations. Then it is a good signal that they might miss something in their arguments. – Bumsik Kim Oct 09 '22 at 12:21
17

Same as other answers: no.

As an illustration, consider the approach chosen by Git 2.19 (Q3 2018), which adds a script (in contrib/) to help users of VSCode work better with the Git codebase.

In other words, generate the .vscode content (if it does not yet exist), don't version it.

See commit 12861e2, commit 2a2cdd0, commit 5482f41, commit f2a3b68, commit 0f47f78, commit b4d991d, commit 58930fd, commit dee3382, commit 54c06c6 (30 Jul 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 30cf191, 15 Aug 2018)

contrib: add a script to initialize VS Code configuration

VS Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux.
Among other languages, it has support for C/C++ via an extension, which offers to not only build and debug the code, but also Intellisense, i.e. code-aware completion and similar niceties.

This patch adds a script that helps set up the environment to work effectively with VS Code: simply run the Unix shell script contrib/vscode/init.sh, which creates the relevant files, and open the top level folder of Git's source code in VS Code.

doelleri
  • 19,232
  • 5
  • 61
  • 65
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
10

Okay, this may seem pretty late, but if you're finding it difficult to ignore .vscode/ without including any sub-file, you could just ignore the directory:

.vscode/

and then manually track the file you want:

git add -f .vscode/launch.json

The -f adds files even when they're ignored. Once Git sees changes to .vscode/launch.json you'll be prompted to commit them just like any other file.

this actually worked for me, caused i experience the same issue, trying to ignore the .vscode/ path, without including a sub-file settings.json

Bravo Stack
  • 111
  • 1
  • 6
4

The answer is "NO",because .vscode folder is for this editor and you should't push these personal settings to repo in case of confusing others ,so you can add it to your project's .gitignore file to ignore the changes

jialin wang
  • 3,214
  • 1
  • 13
  • 5
  • 24
    I would disagree with your strict stance. As mentioned in the answer by @BenjaminPasero, you don't have to, but it makes sense in many cases, e.g. sharing task configuration. Of course, it's good to be mindful of one's teammates and not force preferences on them unnecessarily. – Ronald Zarīts Sep 05 '17 at 14:44
  • 2
    Yes, this is why we have separate user settings and workspace settings (the `.vscode/settings.json` file in a workspace): https://code.visualstudio.com/docs/getstarted/settings#_creating-user-and-workspace-settings Only things such as tool configuration go into the workspace settings – Matt Bierner Sep 05 '17 at 18:20
  • @RonaldZarīts **.vscode**folder is about your own editor's setting and code styles,I think it's just for own use,so as I said before ,don't push the folder to git control flow. – jialin wang Sep 07 '17 at 09:28
  • 9
    @jialinwang Sorry, I already did. ;) Jokes aside, it also contains items that are useful to share, for instance in my project we have (1) `launch.json` - launch configurations for debugging which can be non-trivial to set up. (2) `settings.json` project level settings, like TypeScript compiler to use, whitespace rules, (3) `tasks.json` - build commands. You can choose to not share, but we find it useful. – Ronald Zarīts Sep 13 '17 at 10:04
  • 1
    @jialinwang No they aren't. They are folder-level settings. Not only should you include the top-level one, if you have any settings specific to sub-folders, you should also include those. The important thing is to keep your user preferences *out* of the folder-level settings (this is important for other reasons as well). The kind of things you should have in your folder-level settings should apply to the entire folder: formatters, linters, whitespace conventions (e.g. trim final trailing new lines, tab size...)... – DylanYoung Feb 11 '20 at 19:37
3

A simple way to keep your settings without commit it in your project git repository is creating a workspace and add folder into it.

When do you create a workspace, you need to save a file code-workspace. This file contains custom settings, just save this file out of the git repository and will be free to add .vscode into .gitignore file.

Wendel
  • 2,809
  • 29
  • 28