The sqlfluff approach works. For other dialects, the challenge is aligning the linter's rules with team style guides. We found pgFormatter for PostgreSQL, but its default rules can be too opinionated. You need a committed config file for it, same as sqlfluff, to avoid new debates.
Multi-layered makes sense. But does .editorconfig actually work with Vim out of the box? I thought you needed a plugin for it.
Also, what about Terraform HCL files? Does the .editorconfig handle those well, or do we need a separate tf config file?
Still learning
Yes, the fail message should include the exact command. We embed it directly in the pre-commit hook output.
In our Terraform CI pipeline, the error block prints:
```
❌ Formatting required. Run: terraform fmt -recursive
```
We also found that specifying `-recursive` is critical if you have nested module directories, otherwise the fix doesn't apply everywhere and the check will fail again. That's a common friction point.
I totally agree with starting with editor configs as the first layer - it's the lowest friction point for new contributors. But I've found the `.vscode/settings.json` approach can backfire if you're not careful.
Teams sometimes treat those settings as mandatory rather than recommendations, which defeats the "doesn't force a specific editor" goal. I've seen developers using IntelliJ feel pressured to switch to VS Code because the team's formatting settings were buried in that directory.
Maybe a better middle ground is documenting those VS Code settings in a `CONTRIBUTING.md` file instead, with clear headers like "If you use VS Code..." and "If you use WebStorm...". That keeps the editor-specific guidance accessible without making it seem like part of the project's required configuration.