I expect the formatter/linter to be run as part of presubmit and/or committing the code so it doesn't matter how it's edited and saved by the developer. It's strange to hear of a specific IDE being mandated to work around that, and making quick edits with tools like vi unsupported.

This was with Rider which had its own rules for which we hadn't set up an override in .editorconfig.

allow me to introduce you to the lord and savior, https://pre-commit.com/

Agreed. Also Lefthook: https://github.com/evilmartians/lefthook

and if your pre-commit runs fast (thank you, ruff), you can set this up as a post-edit hook in claude code

I would not recommend this. A hook that modifies files causes Claude to have to re-read the file before modifying it again, which can build up your context window fast

Part of a healthy codebase is ensuring that anyone can hack on it, regardless of their editor setup. Relying on something in .vscode and just assuming people are using that editor is what leads to this kind of situation.

Bake that into the workflow some other way.

Or just enforce that the team all uses the same tools, and you save quite a lot in productivity between making things work on different tools, more so than whatever productivity gains individual devs on the team get from using their own preferred tools. Many teams I know issue everyone MacBooks and enforce VSCode usage, for example, and that has saved so much time compared to other teams I've seen where devs can choose between macOS or Windows for example.

Saves so much time??? Really? You set up a dev env once, how much time is it even possible to save?

No, it's saving time because some things might work on one OS but not another, and then dealing with updates to each OS that might break something, or we need a new piece of software but it doesn't work on Windows for local development, et cetera, et cetera, et cetera. There are so many ways it goes wrong, I speak from personal experience.