i had a minor false-start with <https://github.com...
# development
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
(similar to
, which allows linters to internally partition themselves), as that looked like a good alignment that would allow formatters to batch themselves using the explicit
API that i sketched on the ticket.
but looking at it more, i think that that puts too much on the formatters in the common case.
so now i’m thinking about executing the batching in the
goal itself
and that got me thinking again about having the `lint`/`fmt` goals automatically partition based on
…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.
how would this interact with the partitioning by config file done by the scalafmt rules?
👍 1
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
…or having a computed
to generalize it…
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
or have the core fmt rules provide a default batching implementation that individual fmt rules can use like a library
(i.e., avoid a “framework” like setup of fmt rules)
Batching by computed/AsyncFields seems like a potentially powerful generalization