The helper script can be run in a CI action or a pre-commit git hook (very useful, I also use that for hlint).
If run as a pre-commit hook, wouldn't it always complain about a dirty working directory then as before a commit changes aren't commited yet?
And finally, a stylish-haskell helper script that detects if code files are dirty. Can be useful for CI, although manually calling it can be nice if you would rather first implement then beautify.
@hecate I do not fully understand what's the best way of using stylish-haskell in my workflow:
On the one hand I'm too lazy for calling the tool itself for each single file of my project.
When using the helper script, I usually commit my changes first, then run the heloer script and --amend the formatting changes to the previous commit. This only works though when always committing all changes from the repo, not only those of a single file or even a chosen patch set.
Why does the helper script care about a dirty working directory?
This one pulls in Postgres. I still have to decide on how to persist data, will probably ask around in the SocialHub thread quite soon.
Note to self for further reading: https://www.haskelltutorials.com/odd-jobs/haskell-job-queues-ultimate-guide.html
The DHT layer also needs to schedule regular maintenance jobs, but as those won't pile up such an asynchronous background processing worker queue isn't necessary.