3 ms·

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.

by 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
        One user programmatically changing things to suit themselves is supposed to do so in their user settings, which has precedence over the checked-in copy. That way, you have the best of both worlds: easy set-up for everyone who wants it but you can override it without touching the VCS.
        Hackbraten 4y ago
        Update: turns out the precedence rules are a little more subtle than I thought. See also: https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence https://code.visualstudio.com/docs/getstarted/settings#_sett...
        DangitBobby 4y ago
        Can you override user settings at the project level?
        Hackbraten 4y ago
        Yes, project-level (aka workspace) settings generally override user settings. But then again, language-specific settings will trump all other settings. And that’s one way to override workspace-level settings in your user settings if you want. Here’s a detailed list of all levels of settings in VS Code, ordered by precedence: https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence https://code.visualstudio.com/docs/getstarted/settings#_sett...
roykanesmith37 4y ago
Java projects can get complex and editors (like IntelliJ can provide much better tooling when configured). 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. It’s definitely not a never situation. You can commit only certain files from the configuration (project settings not editor preferences)

by 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
      One user programmatically changing things to suit themselves is supposed to do so in their user settings, which has precedence over the checked-in copy. That way, you have the best of both worlds: easy set-up for everyone who wants it but you can override it without touching the VCS.
      - Hackbraten 4y ago
        Update: turns out the precedence rules are a little more subtle than I thought. See also: https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence https://code.visualstudio.com/docs/getstarted/settings#_sett...
      - DangitBobby 4y ago
        Can you override user settings at the project level?
        Hackbraten 4y ago
        Yes, project-level (aka workspace) settings generally override user settings. But then again, language-specific settings will trump all other settings. And that’s one way to override workspace-level settings in your user settings if you want. Here’s a detailed list of all levels of settings in VS Code, ordered by precedence: https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence https://code.visualstudio.com/docs/getstarted/settings#_sett...

roykanesmith37 4y ago

Java projects can get complex and editors (like IntelliJ can provide much better tooling when configured). 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. It’s definitely not a never situation. You can commit only certain files from the configuration (project settings not editor preferences)