VS Code teams struggle to share settings without blocking overrides
Teams want shared VS Code project defaults while letting developers keep personal or machine-specific preferences; IT administrators also want consistent settings across users. The requests describe relying on checked-in workspace files, awkward source-control exclusions, and extension boilerplate to manage configuration. These signals date from 2017–2018, so current unmet demand should be validated against VS Code's evolving features.
For VS Code development teams and IT administrators. Mentioned from Jun 2017 to Dec 2020 on GitHub.
7 different people described this problem in 4 separate discussions.
- Indie fit
- 3.0/10
- Pain
- 6.0/10
- Frequency
- 7.5/10
- Willingness to pay
- 0.0/10
- Momentum
- 5.0/10
- Who pays
- Businesses
- Competition
- Medium
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
The use case for this is that a team may want to track and distribute shared settings for a folder (using the existing settings.json), but give individual users the flexibility to opt out of those settings (via settings.user.json)
Currently you'd have to make that change in the team .vscode/settings.json file, which sucks because you'd the either have to check it in to source control for the whole team, or add the file to .git/info/exclude (in which case every time you do need to update the file in source control, you have to undo the exclusion,…
Build brief
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 4 places to find your first customers
- 6 more quotes from people who have this problem
- Current workarounds, existing solutions and risks