I've just noticed while writing the above that #138 takes the opposite approach and sets fourmolu +dev. This would frustrate my local workflow.

My preference would be to turn on the dev flag in both cabal.project and stack.yaml. You could always turn it off ad-hoc with --ghc-options -Wwarn, but I think enabling it by default is a Good Thing.

Personally, I would be very frustrated that a working build locally with default settings fails on CI. I expect a passing git clone + stack test locally should pass CI

I expect a passing git clone + stack test locally should pass CI

Ah. Well I wouldn't, in the same way that I wouldn't expect running stack test to check for HLint warnings, or bad formatting.

🤷 ok, up to you. You can remove -Werror from all the stack.yaml files, then.

shrug ok, up to you. You can remove -Werror from all the stack.yaml files, then.

I think I'll have to, sorry. Is it easy enough to re-enable locally to get the behaviour you want (I'm not very familiar with Stack)?

Perhaps it's worth starting an r/haskell thread or similar to find out what other people do here, and why. In my other projects, including at work, -Werror has only ever been enabled on CI.

The right course of action in that case would actually be to remove all references to -Werror in fourmolu.cabal, rather than removing the dev flag. Which also avoids merge conflicts with #138.

I think I'll have to, sorry. Is it easy enough to re-enable locally to get the behaviour you want (I'm not very familiar with Stack)?

It's easy either way. To turn it on, you just add --ghc-options -Werror to your stack build command. With it turned on by default in stack.yaml, you could turn it off by adding --ghc-options -Wwarn to your stack build command. Personally, I like turning it on by default because it's easier to forget to turn on than turn off.

(My other argument is also that Ormolu devs turn on the dev flag locally by default, so why not do the same?)

The right course of action in that case would actually be to remove all references to -Werror in fourmolu.cabal, rather than removing the dev flag. Which also avoids merge conflicts with #138.

No, -Werror in fourmolu.cabal is always behind the dev flag, so there's no point keeping it in. Plus, removing it in three locations in fourmolu.cabal increase the likelihood of merge conflicts than just removing the line in cabal.project (plus, fourmolu.cabal will be touched more often upstream than cabal.project)

Keep the change to cabal.project, don't change fourmolu.cabal, and remove -Werror from the stack*.yaml files. I already updated #138 to avoid conflicts with whatever happens in this PR

No, -Werror in fourmolu.cabal is always behind the dev flag, so there's no point keeping it in. Plus, removing it in three locations in fourmolu.cabal increase the likelihood of merge conflicts than just removing the line in cabal.project (plus, fourmolu.cabal will be touched more often upstream than cabal.project)

Well, on the other hand, for the sake of argument:

• We'd then miss out on some extra warnings (but admittedly nothing terribly important - -Wincomplete-uni-patterns is even on by default since GHC 9.2, although somehow this didn't make it in to the release notes...)
• Those lines are unlikely to change at all often.

But I don't really care much either way, so I'll do it your way!

Well either way, we'll need to make sure to add the dev flag on CI

Rebase against master and resolved comments according to discussion:

• Keep dev flag + -Werror off by default with both cabal and stack
• Keep dev flag + -Werror in cabal file (avoids conflicts with upstream)
• Add dev flag + -Werror to CI

To reiterate, I personally think dev/Werror should be on by default, since it's easy to turn off if you make changes and want to temporarily turn off warnings (both cabal + stack support --ghc-options=-Wwarn to the build command), and it's easier to remember to turn off errors than to remember to turn them on. But I'd much rather we merge something than leave things as-is, hence the changes above.

To try to reduce number of open PRs, I'm merging this as soon as CI passes. If changes are desired, we can open up another PR.