i had a minor false start with

Question

i had a minor false start with <https github com pantsbuild pants issues 13462> this afternoon in that i started on adapting all formatters to return `FmtResults` similar to `LintResults` which allows linters to internally partition themselves as that looked like a good alignment that would allow formatters to batch themselves using the explicit `BatchProcess` API that i sketched on the ticket

witty-crayon-22786 · Answer

but looking at it more i think that that puts too much on the formatters in the common case

witty-crayon-22786 · Answer

so now i m thinking about executing the batching in the `fmt` goal itself

witty-crayon-22786 · Answer

and that got me thinking again about having the `lint` `fmt` goals automatically partition based on `FieldSet` values

witty-crayon-22786 · Answer

slightly orthogonal actually but i guess my main point is formatters or linters needing to return batches of results means that they are internally doing partitioning which we might be able to do outside

fast-nail-55400 · Answer

how would this interact with the partitioning by config file done by the scalafmt rules

witty-crayon-22786 · Answer

i don t think that it would be powerful enough to replace that since it s based on more than just the fields of the targets but i could imagine the backends having optional partitioning rules

witty-crayon-22786 · Answer

or having a computed `ScalafmtConfigField` to generalize it

hundreds-father-404 · Answer

I m curious if we could have a plugin hook where you can do custom batching else do the default perhaps But not clear to me how to handle if you want your new batching at the same time as existing batching

fast-nail-55400 · Answer

or have the core fmt rules provide a default batching implementation that individual fmt rules can use like a library

fast-nail-55400 · Answer

i e avoid a framework like setup of fmt rules

witty-crayon-22786 · Answer

Batching by computed AsyncFields seems like a potentially powerful generalization