Consider providing an option to bunch `project` together and `libs` in a separate bunch, regardless of using `implementation` or `api`
StylianosGakis opened this issue · 1 comments
So consider this case. I got this dependencies block
dependencies {
api(libs.turbine)
api(libs.turbine2)
api(libs.turbine3)
api(projects.core.commons)
api(projects.core.commons2)
implementation(libs.slimber)
implementation(libs.slimber2)
implementation(libs.slimber3)
implementation(projects.core.other)
implementation(projects.core.other2)
}
I feel like, it provides more value for such a configuration to be sorted like this instead
dependencies {
api(libs.turbine)
api(libs.turbine2)
api(libs.turbine3)
implementation(libs.slimber)
implementation(libs.slimber2)
implementation(libs.slimber3)
api(projects.core.commons)
api(projects.core.commons2)
implementation(projects.core.other)
implementation(projects.core.other2)
}
So that one can see the other modules it is depending on bunched together, and then on a separate block see the libraries. I feel like this is more important than bunching them by if they are api
or implementation
, as then you may be splitting apart which modules it is depending on which may make it much harder to easily peek and see which module dependencies this module has.
p.s Or even like this in my personal opinion, as it's nice to be able to pop into a build.gradle file and at the top level see which other modules it is depending on, which feels more important than which libraries it is depending on
dependencies {
api(projects.core.commons)
api(projects.core.commons2)
implementation(projects.core.other)
implementation(projects.core.other2)
api(libs.turbine)
api(libs.turbine2)
api(libs.turbine3)
implementation(libs.slimber)
implementation(libs.slimber2)
implementation(libs.slimber3)
}
I would understand if you think this goes against the nature of this plugin, if you want it to be a simple sorter without more than that, but just asking here to see if it is something that you would be open to consider or not. Even if such a configuration is optional and configurable on the gradle plugin itself.
I think a better solution would be to offer some sort of serviceloader API that allows people to bring their own sorting impl. Suggestions welcome on an API for that instead