My experience using it in a large project is seeing a lot of unformatted PR's, vs more mainstream tools like prettier etc. I think the main issue here is that the vscode extension uses separate config vs the cli/js version, and that there aren't extensions for other popular editors like jetbrains, zed etc. Also if you have a lot of projects that use json, and you want to adopt this in one of them, a lot of engineers are not going to bother setting up their env to handle different auto-formatting across workspaces. And some will say they prefer to run the formatting via cli then frequently forget to.
this post was submitted on 03 Jan 2026
8 points (100.0% liked)
JavaScript
2621 readers
19 users here now
founded 2 years ago
MODERATORS
pre commit hook and ci task. even with common formatters like prettier I do that on anything somewhat large
Yeah, but do you really want CI making commits in your git history? Haven't thought too much about it but I'm assuming it could get gnarly. In larger teams I often see stuff that could not possibly have passed the existing pre-commit hook. Actually on one of our projects the unit tests run on precommit and it takes 8 minutes on my machine, so you could call me a git hook skeptic.
No, CI validates that the hooks or formatter ran, and fails if not. in theory it shouldn't ever fail but it's to catch the stuff that couldn't have passed the commit hook.
the hooks are easy to turn off and can be hard to get to reliably run (90% of the time they're fine, but all of the tools that run git commands sometimes do weird things), but they're a best effort kind of thing.
unit tests on precommit are a little annoying, especially when it takes that long. that's better suited to running in ci afterwards since there's no advantage to running before you commit. formatter takes like 200ms max for affected files? you won't notice, and it ends up as part of the one commit
Sounds like a plan, maybe I can try used FJ again, it does looks nicer than prettier or biome.