Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable opting out of workspace settings / .vscode/settings.json #206802

Closed
voxpelli opened this issue Mar 4, 2024 · 4 comments
Closed

Enable opting out of workspace settings / .vscode/settings.json #206802

voxpelli opened this issue Mar 4, 2024 · 4 comments
Assignees
Labels
*out-of-scope Posted issue is not in scope of VS Code

Comments

@voxpelli
Copy link

voxpelli commented Mar 4, 2024

Unlike #40233 – which is about separating local workspace settings from shared workspace settings – I would primarily want a way to disable workspace settings in its entirety.

Most basic solution of all:

Have a user setting that disables the use of workspace settings.

Why do I want this?

I sometimes get very confused when I open up a repository shared with someone else and all of the sudden my editor starts eg. formatting on save etc when I work with files there – and even when I figure that out there's no way for me to avoid it other than convincing my collaborators to remove the workspace settings from the repository.

I can never think of a scenario where I personally would prefer to use settings from someone else, but I can see how others may like it.

Having an option to opt out of the shared settings would help avoid a lot of conflict and friction within teams and projects.

Is this a duplicate?

Unlike eg. #40233 and #89737 (which was marked a duplicate of #40233) this isn't about individual rules, this is about opting out of workspace settings entirely.

@sandy081
Copy link
Member

sandy081 commented Mar 5, 2024

Primary intention of workspace/repo settings is to allow users collaborating with that workspace to have similar and stream lined experience. Ignoring it can lead to issues like breakages. I do not think it is a good idea to allow such a feature in the product that can break the team experience. If a user does not like or change some settings/guidelines, it is recommended to make that change in the team guidelines.

@voxpelli
Copy link
Author

voxpelli commented Mar 5, 2024

The current situation breaks the team experience as it forces me to have to convince my colleagues to change settings or for me to do workarounds, like patching the checked out repo or swapping to another editor (or disabling the extensions that eg are configured to do auto formatting)

A team experience is enforced through CI and scripts, not through UI.

Also:

When forking a GitHub repository to do PR:s I will get the team settings of a fully unknown team and will get random surprises in how the editor works depending on which repository ai’m currently contributing to, with no way of really knowing what changes and when. It disrupts my muscle memory and can’t be fixed by “talking to my team”.

I should be able to make PR:s with VSCode without being forced upon the settings of other teams. (I maybe can achieve this by marking the repo as not trusted, but that’s very disruptive and far further reaching. It’s not that I don’t trust them, it’s that I can’t instantly adapt my muscle memory to each and every project I contribute to)

At least leave it open for some discussion? And then close it as “not planned” rather than “completed” when closing? 🥺

@sandy081 sandy081 added *out-of-scope Posted issue is not in scope of VS Code and removed wont-fix labels Mar 7, 2024
@sandy081
Copy link
Member

sandy081 commented Mar 7, 2024

A team experience is enforced through CI and scripts, not through UI.

Thats right and team settings should help in catching any CI failures upfront and make it efficient.

At least leave it open for some discussion? And then close it as “not planned” rather than “completed” when closing?

I can do this to make you happy, but I have to say this is out of scope feature.

@voxpelli
Copy link
Author

voxpelli commented Mar 8, 2024

team settings should help in catching any CI failures upfront and make it efficient

Only holds true when one is also enforcing the editor of choice and especially when contributing to open source projects editors will not be forced upon contributors, so not sure why settings should be.


For future reference to others finding this issue:

One can use the assume-unchanged git feature to remove it locally while having git treat it as unchanged (found out thanks to suggestions on Mastodon!):

git update-index --assume-unchanged .vscode/settings.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
*out-of-scope Posted issue is not in scope of VS Code
Projects
None yet
Development

No branches or pull requests

2 participants