For us, its a pre-commit hook to format with pretty-quick on all staged files. Use whatever IDE you want (although I recommend VScode for the team), but our code will be formatted the same regardless.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
And that works well too. If you work on a team and on a product/platform, one code base, autoformatting helps everyone stay consistent. I won't disagree there.
Once you start splitting projects and switching between teams and other products you'll quickly find the code doesn't keep the same formatting, even if you enforce the hell out of it, in the long term it won't stay that way, someone will mess it up along the way and you'll spend more time arguing about how to fix the formatting than it's even worth doing. Seeing this with a current client whose dev team spends more time doing code reviews than actually building anything.
For us, its a pre-commit hook to format with pretty-quick on all staged files. Use whatever IDE you want (although I recommend VScode for the team), but our code will be formatted the same regardless.
And that works well too. If you work on a team and on a product/platform, one code base, autoformatting helps everyone stay consistent. I won't disagree there.
Once you start splitting projects and switching between teams and other products you'll quickly find the code doesn't keep the same formatting, even if you enforce the hell out of it, in the long term it won't stay that way, someone will mess it up along the way and you'll spend more time arguing about how to fix the formatting than it's even worth doing. Seeing this with a current client whose dev team spends more time doing code reviews than actually building anything.
We've been using nx.dev/ for our mono repo for all of our front-end work.