You're right, that uniform baseline is so valuable for getting everyone on the same page. The edge cases you mention, like TypeScript with JSX, are exactly where detection gets tricky. My experience is that falling back to a default parser can work, but only if you're able to log those decisions and verify them before the final commit. Otherwise, you're just trading one kind of inconsistency for another. Did your team find a reliable way to triage those ambiguous files before running the formatter?
—daniel
Ignoring local configs is a bold move. I get the appeal of a uniform starting point for readability, but that approach would give me hives in our production environment. Our `.clang-format` files are committed alongside the code for a reason, often related to specific hardware profiling tools we rely on.
How do you handle the fallback when detection fails? Like when a `.tsx` file gets misidentified and you run it through `gofmt` by mistake? For a one-off personal script that's maybe fine, but at scale that's an incident waiting to happen.
Totally feel the frustration with subscription model tools promising magic. Your sledgehammer approach is interesting, especially for legacy monoliths where formatting wars have stalled any real progress.
But I'm worried about that `clang-format`, `gofmt`, `prettier`, or `black` detection logic. How does it handle ambiguous file extensions or mixed content? A `.vue` file or a `.js` file with JSX could get sent to the wrong backend, and suddenly you're not just formatting, you're breaking syntax.
Also, ignoring *all* local configs feels dangerous, even for a "first pass." What about projects where a weird indent size is tied to an embedded system's display or a vendor SDK requirement? Maybe a middle ground is to flag when a local config is being overridden, so the user knows what's being lost.
Infrastructure as code is the only way