5 ms·

Why to ignore .vscode? We collect there workspace wide team settings.

by AlfeG 4y ago

sph 4y ago
I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.
- downsidesabound 4y ago
  If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
  - pjerem 4y ago
    When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
    - ascagnel_ 4y ago
      I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.
  - sph 4y ago
    I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case. What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
    - roykanesmith37 4y ago
      At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
      - shagie 4y ago
        I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file. Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else. I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use. Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar. Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
- abdouls 4y ago
  I've seen a few big repositories upload their .vscode (pretty sure at least one of the Microsoft repos on Github had this). I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).
- bloopernova 4y ago
  What about .editorconfig?
  - sph 4y ago
    That's perfectly fine, mandatory even if more than one person touches the code.
- blueberrychpstx 4y ago
  you didn't list .idea :'(
junon 4y ago
Please never commit IDE config. It doesn't belong in repositories. It is not a source file of your project.
- dougdonohoe 4y ago
  Actually, this can be quite useful (at least with IntelliJ) to share common run configurations (e.g., run all tests, start this server with these settings) and other settings. IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems https://intellij-support.jetbrains.com/hc/en-us/articles/206...
  - sph 4y ago
    Makefile or adding those scripts to package.json is a much better idea than vscode's own task configuration file which might not work if someone uses another editor.
    - fomine3 4y ago
      Why not both?
- jameshart 4y ago
  'never' is a strong word. A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project. If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to: git clone <project> git switch -t <branch> code <project> npm ci | dotnet restore | terraform init | go get | <whatever> <change and test> git add <changes> git commit git push With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes. It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.
dharmab 4y ago
Most teams I worked on did not standardize the team's OS or editor. The "canonical" build was a CI server and the development environment was available as a VM or container.
rubyist5eva 4y ago
For the love of God no. I had someone commit theirs and it override my preferred setup and even changed my gd font. You're basically telling your teammates: i am forcing you to work my way so shove it.

Why to ignore .vscode? We collect there workspace wide team settings.

by AlfeG 4y ago

Why to ignore .vscode? We collect there workspace wide team settings.

sph 4y ago

I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.

downsidesabound 4y ago
If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
- pjerem 4y ago
  When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
  - ascagnel_ 4y ago
    I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.
- sph 4y ago
  I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case. What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
  - roykanesmith37 4y ago
    At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
    - shagie 4y ago
      I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file. Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else. I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use. Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar. Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
abdouls 4y ago
I've seen a few big repositories upload their .vscode (pretty sure at least one of the Microsoft repos on Github had this). I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).
bloopernova 4y ago
What about .editorconfig?
- sph 4y ago
  That's perfectly fine, mandatory even if more than one person touches the code.
blueberrychpstx 4y ago
you didn't list .idea :'(

junon 4y ago

Please never commit IDE config. It doesn't belong in repositories. It is not a source file of your project.

dougdonohoe 4y ago
Actually, this can be quite useful (at least with IntelliJ) to share common run configurations (e.g., run all tests, start this server with these settings) and other settings. IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems https://intellij-support.jetbrains.com/hc/en-us/articles/206...
- sph 4y ago
  Makefile or adding those scripts to package.json is a much better idea than vscode's own task configuration file which might not work if someone uses another editor.
  - fomine3 4y ago
    Why not both?
jameshart 4y ago
'never' is a strong word. A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project. If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to: git clone <project> git switch -t <branch> code <project> npm ci | dotnet restore | terraform init | go get | <whatever> <change and test> git add <changes> git commit git push With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes. It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.

dharmab 4y ago

Most teams I worked on did not standardize the team's OS or editor. The "canonical" build was a CI server and the development environment was available as a VM or container.

rubyist5eva 4y ago

For the love of God no. I had someone commit theirs and it override my preferred setup and even changed my gd font. You're basically telling your teammates: i am forcing you to work my way so shove it.