rfc: pin ormolu and check formatting in CI

[hellerve]

in #1573 we hit a large re-format, because @iwami4438 pre-commit hook ran a current ormolu (0.7.2.0) while the codebase is formatted with a much older one (my local copy turns out to be 0.1.0.0, from 2020, i think i’m old?!). ormolu changed its style between those versions, so everyone's hook fights everyone else's. the version isn't pinned, CI doesn't check formatting, and the hook reformats and stages silently, so nobody sees it happen, it just goes in the commit.

my proposal:

1. we pin the ormolu version. record it in a single place (e.g. ormolu.version at the repo root, read by scripts/format.sh, or directly in the format script). format.sh would then refuse to run if ormolu --version doesn't match, with install instructions. i'd pin to the current release rather than an old one, since that's what stack install / brew hands people. it would mean that we’d have to keep it current or force people to downgrade their ormolu, though?
2. we make a one-time reformat commit: run the pinned ormolu over all the source code in a dedicated commit.
3. add a CI check, just a small workflow using haskell-actions/run-ormolu with mode: check and the pinned version. then we catch early if we stray from the path.
4. we make the hook check instead of mutate (pre-commit runs ormolu --mode check on staged files instead of just rewriting and git adding). contributors see what changes, and we don’t need to --no-verify. (the current auto-git add also breaks partial staging, which is not cool!)

wdyt?

cheers

[eriksvedang]

I'm all for it!

[iwami4438]

The fundamental issue, I believe, is that different versions of Ormolu result in significant commit diffs, making code reviews difficult.

I will leave the choice of version to the reviewer, but there are trade-offs to consider. Using the latest version would necessitate a one-time large-scale reformatting and result in larger diffs for future changes. While an older version like 0.1.0 could avoid this, it raises concerns regarding CI and dependencies.

In any case, the root cause appears to be the lack of version pinning, so I consider addressing this to be the most important solution. Please let me know if I have overlooked anything.

Note: If we decide to use version 0.1.0, it appears that only version 0.1.3.0 has been released on GitHub (version 0.1.0 was available only on Hackage). It might be worth verifying this.

[hellerve]

I think a one-time reformat commit is fine as long as we remember to keep it current and consistent afterwards then. I think pinning CI to something like 0.8.2.0 right now would be optimal.