Later when I git status or just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.
You probably already know this, but for those who don’t, git can globally ignore patterns. It’s the first thing I set up after logging in. Honestly wish git just shipped this way out of the box (maybe match .DS_Store by name and some magic bytes?) with a way to disable it. Just for the sake of easier onboarding
I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.
As you should. Because the alternative is just putting it on some team wiki page where they’ll just copy and paste it to their local stuff anyways. It just saves everyone time.
If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.
Absolutely nothing wrong. Their whole argument is that it delivers no guarantees about the things set in these files, but setting these presets is more about convenience than enforcing an equal development environment.
Whoever needs to enforce things like formatting and linting at the project level should be using a CI step.
Sure, fail the entire build because of a formatting problem. Hey, wouldn’t it be cool if we could stop that from happening? I don’t know, maybe by also adding in IDE specific formatting files? No? Oh. I wasn’t aware we could only have formatting files OR a CI format checker. 🙄
None of these things come at the expense of others. You can do both. Even if it’s part of the local build process I’d much rather know in my editor than on the terminal. And you may say “just have everyone do the same setup” to which I’d wonder what sort of magical land you live in where everyone always follows those rules and/or you can get buy in from management to spend that much time bike shedding and why you’d prefer either of them to just adding the damn file to version control to avoid it entirely.
.vscode doesn’t store cache or any trash like that, so if you’re including all settings, tasks, etc, you can probably just include everything.
The only thing to keep in mind is to only add settings, extension recommendations, etc that apply to all your collaborators and aren’t just personal preferences. A few good examples are formatting rules, task definitions to run the project, and linting rules that can’t be defined somewhere else.
Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.
I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.
As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.
Linting rules and scripts should never live in an IDE-specific directory.
Of course they should. Obviously it shouldn’t be the only place they are, but committing IDE code styles settings that match the externally-enforced project styles is absolutely helpful.
Or, in our project we have a bunch of scripts that you can run manually, but we also have commited IntelliJ run configurations that make running them a convenient in-IDE action.
linting config itself wouldn’t be defined there, and it would be verified in ci and such, but a setting to tell vscode which linter and extension it should use to show warnings would be.
modern languages may have their own way for configuration but they don’t have a way to bind it to the list of vscode tasks and define how to run a debugger, which is the part that gets stored.
it’s easy to go overboard with extension suggestions, but I don’t think adding an extension for linter used, extension for formatter used, and any languages used if there’s a definitive extension.
My team is split between visual studio, vscode, and I use emacs. we have config for both vs and vscode in our repos since it makes working on a new project so much nicer and means we aren’t just sharing editor configs through side channels instead. it doesn’t do anything to me if I have editor config for an IDE I don’t use in the repo, but it makes it easier for someone new to jump in with a sort of same environment immediately
It’s okay to commit IDE config if your team uses mostly one editor.
It’s also okay to include extension recommendations. While extensions may not be needed to run the code, depending on the editor and language they’re highly desirable. It’s that kind of extension that should be recommended. I’m sure there’s a setting to disable them if, for some reason, the editor keeps asking you.
Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.
This is what I’m getting at with it being cargo culty. You can have generic scripts and also IDE specific run configurations too.
Just gitignore that. Same for dot idea and whatever vscode adds, if anything
You can add
.DS Storein your global gitignore at~/config/git/ignoreYa, but that .idea is not inserted in eleven thousand sub folders.
It’s not, but I still prefer not pushing my config on others, or others pushing theirs on me.
git add .>git commit -m "initial">git pushLater when I
git statusor just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.You probably already know this, but for those who don’t, git can globally ignore patterns. It’s the first thing I set up after logging in. Honestly wish git just shipped this way out of the box (maybe match .DS_Store by name and some magic bytes?) with a way to disable it. Just for the sake of easier onboarding
Use this so that the things you need to share do get shared.
.idea/* !.idea/codeStyles !.idea/runConfigurations .vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json !.vscode/*.code-snippetsNote: I haven’t checked the vs code ones in depth, the list might not be perfect.
I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.
I get this but I commit my vscode run configuration and testing env vars.
As you should. Because the alternative is just putting it on some team wiki page where they’ll just copy and paste it to their local stuff anyways. It just saves everyone time.
That’s exactly my thinking.
If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.
Absolutely nothing wrong. Their whole argument is that it delivers no guarantees about the things set in these files, but setting these presets is more about convenience than enforcing an equal development environment.
Whoever needs to enforce things like formatting and linting at the project level should be using a CI step.
Sure, fail the entire build because of a formatting problem. Hey, wouldn’t it be cool if we could stop that from happening? I don’t know, maybe by also adding in IDE specific formatting files? No? Oh. I wasn’t aware we could only have formatting files OR a CI format checker. 🙄
None of these things come at the expense of others. You can do both. Even if it’s part of the local build process I’d much rather know in my editor than on the terminal. And you may say “just have everyone do the same setup” to which I’d wonder what sort of magical land you live in where everyone always follows those rules and/or you can get buy in from management to spend that much time bike shedding and why you’d prefer either of them to just adding the damn file to version control to avoid it entirely.
yeah, also why I do both
.vscodedoesn’t store cache or any trash like that, so if you’re including all settings, tasks, etc, you can probably just include everything.The only thing to keep in mind is to only add settings, extension recommendations, etc that apply to all your collaborators and aren’t just personal preferences. A few good examples are formatting rules, task definitions to run the project, and linting rules that can’t be defined somewhere else.
Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.
I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.
As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.
Of course they should. Obviously it shouldn’t be the only place they are, but committing IDE code styles settings that match the externally-enforced project styles is absolutely helpful.
Or, in our project we have a bunch of scripts that you can run manually, but we also have commited IntelliJ run configurations that make running them a convenient in-IDE action.
linting config itself wouldn’t be defined there, and it would be verified in ci and such, but a setting to tell vscode which linter and extension it should use to show warnings would be.
modern languages may have their own way for configuration but they don’t have a way to bind it to the list of vscode tasks and define how to run a debugger, which is the part that gets stored.
it’s easy to go overboard with extension suggestions, but I don’t think adding an extension for linter used, extension for formatter used, and any languages used if there’s a definitive extension.
My team is split between visual studio, vscode, and I use emacs. we have config for both vs and vscode in our repos since it makes working on a new project so much nicer and means we aren’t just sharing editor configs through side channels instead. it doesn’t do anything to me if I have editor config for an IDE I don’t use in the repo, but it makes it easier for someone new to jump in with a sort of same environment immediately
Can we stop with the absolutes?
It’s okay to commit IDE config if your team uses mostly one editor.
It’s also okay to include extension recommendations. While extensions may not be needed to run the code, depending on the editor and language they’re highly desirable. It’s that kind of extension that should be recommended. I’m sure there’s a setting to disable them if, for some reason, the editor keeps asking you.
This is what I’m getting at with it being cargo culty. You can have generic scripts and also IDE specific run configurations too.