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.
No, you should not add it to source control. The purpose of this folder is to move machine- and user-specific files to a central location. The explanation on the Visual Studio User Voice issue explains it well: So far, we have moved the .
At its heart, Visual Studio Code is a code editor. Like many other code editors, VS Code adopts a common user interface and layout of an explorer on the left, showing all of the files and folders you have access to, and an editor on the right, showing the content of the files you have opened.
No, it's not possible to move/rename that folder. VS code is a tool that bases project management on folder content. So it is essential that the project settings reside in the folder being managed.
Recommendation is to generally exclude .vscode
folder, but leave select JSON files that allow other developers to recreate shared settings.
Examples of settings to include:
settings.json
)settings.json
)launch.json
)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.
.gitignore
codeHere 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.
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 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..).
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.
*.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.
.vscode/settings.json
to have an absolute path of the current folder under the pythonpath
setting, which makes it specific to the current PC.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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With