https://pantsbuild.org/ logo
Join Slack
Powered by
i had a minor false-start with <https://github.com...
# development
w
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.
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 
fmt
goal itself
and that got me thinking again about having the `lint`/`fmt` goals automatically partition based on 
FieldSet
values
…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.
f
how would this interact with the partitioning by config file done by the scalafmt rules?
👍 1
w
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 
ScalafmtConfigField
to generalize it…
h
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
f
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)
w
Batching by computed/AsyncFields seems like a potentially powerful generalization
Open in Slack
PreviousNext
Powered by