4 ms·

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

by junon 4y ago

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.
- junon 4y ago
  Never is a strong word, and I mean it. No your fancy extensions mean nothing to many devs. That configuration is not required to run the code in the repository. Do not include it.
  - jameshart 4y ago
    So... are you also against having any hints as to how to set up a working local dev environment in the README.md file? Because that's also not necessary to run the project, but it's a courtesy to contributors. Also, the idea that there is some universal rule of 'what should be checked in to source control' that applies to EVERYTHING from personal projects to corporate internal monorepos to open source projects to undergrad joint coding projects to video games is... absurd.
    - junon 4y ago
      No, because that's documentation, but I think that was obvious.
      - jameshart 4y ago
        Well, no it's not obvious. If I can provide machine readable documentation on how to get your VSCode environment set up (in the form of a .vscode/extensions.json file), isn't that strictly better than merely human-readable documentation in README.md under a 'Recommended VSCode Extensions to work with this project' header?
        junon 4y ago
        No, because that doesn't translate to other IDEs and one user programmatically changing things to suit themselves causes fluff in PRs and diffs. You also can't guarantee every environment is going to respond correctly.
        Hackbraten 4y ago
jonnycomputer 4y ago
I think I disagree, though the only person who should be messing with it is the maintainer. One of the easiest ways to ensure that everyone follows the same coding standard for a project (particularly for open source projects). I usually add something like specified in: https://editorconfig.org/ https://editorconfig.org/
- junon 4y ago
  But there's a difference between editorconfig and vscode specific stuff in that editorconfig is IDE agnostic...
  - jonnycomputer 4y ago
    Yes; would be silly to dictate people's font sizes and the like. Perhaps we can then agree that there are certain configs that do belong, and others that might be less wise to include [if your boss dictates that you use Arial 10pt, get another job!]

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

by junon 4y ago

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

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.

junon 4y ago
Never is a strong word, and I mean it. No your fancy extensions mean nothing to many devs. That configuration is not required to run the code in the repository. Do not include it.
- jameshart 4y ago
  So... are you also against having any hints as to how to set up a working local dev environment in the README.md file? Because that's also not necessary to run the project, but it's a courtesy to contributors. Also, the idea that there is some universal rule of 'what should be checked in to source control' that applies to EVERYTHING from personal projects to corporate internal monorepos to open source projects to undergrad joint coding projects to video games is... absurd.
  - junon 4y ago
    No, because that's documentation, but I think that was obvious.
    - jameshart 4y ago
      Well, no it's not obvious. If I can provide machine readable documentation on how to get your VSCode environment set up (in the form of a .vscode/extensions.json file), isn't that strictly better than merely human-readable documentation in README.md under a 'Recommended VSCode Extensions to work with this project' header?
      - junon 4y ago
        No, because that doesn't translate to other IDEs and one user programmatically changing things to suit themselves causes fluff in PRs and diffs. You also can't guarantee every environment is going to respond correctly.
        Hackbraten 4y ago

jonnycomputer 4y ago

I think I disagree, though the only person who should be messing with it is the maintainer. One of the easiest ways to ensure that everyone follows the same coding standard for a project (particularly for open source projects). I usually add something like specified in: https://editorconfig.org/ https://editorconfig.org/

junon 4y ago
But there's a difference between editorconfig and vscode specific stuff in that editorconfig is IDE agnostic...
- jonnycomputer 4y ago
  Yes; would be silly to dictate people's font sizes and the like. Perhaps we can then agree that there are certain configs that do belong, and others that might be less wise to include [if your boss dictates that you use Arial 10pt, get another job!]