kamadorueda
commented
2 years ago we currently run each linter/formatter on a different job, on a different machine on CI,
this have some benefits:
- it's faster, because each machine runs 1 piece of the N linters and machines work in parallel. This is faster than 1 machine running the N linters alone
- cache is done separately, so if I modify only python code, only python linters run, therefore most linters/formatters are a no-op the majority of the time (just downloading an empty file from the cache) like this:
- this increases developer productivity as they have to wait less for the pipeline to complete, therefore saving dev time ($$$) && increasing time2market
and some trade-offs:
- you use more machine time in total, so more aws bill $$$
- with treefmt we would have 1 command locally instead of N as today, that's nice
for the last part, I don't remember the last time I had to run a formatter locally, it's embedded in my editor: https://github.com/kamadorueda/machine/blob/main/src/config/system/userActivationScripts/vscode/default.nix#L26 linters are there too
blaggacao
zimbatm has finally gotten around to do https://github.com/numtide/treefmt
This is a standardized code formatter that should work uniformly and in parallel around many code formatters out there and work smoothly (enough) with editors, written in rust.
I think
makeswould benefit a great deal embracing this project, because of rust-like concurrency, but most of all, because of easy editor integration, rust-speed file walker (bash&nixafaik are slow) and a reasonably simple configuration format.