.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.
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.
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
.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.
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.
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