Enforce whitespace between configuration sets

[StylianosGakis]

For a block like this

dependencies {
  implementation(libs.turbine)
  api(libs.analytics)
  implementation(projects.events)
}

If I run the gradle plugin I will get the result:

dependencies {
  api(libs.analytics)

  implementation(libs.turbine)
  implementation(projects.events)
}

---

But for a block like this:

dependencies {
  api(libs.analytics)
  implementation(libs.turbine)
  implementation(projects.events)
}

If I run the gradle plugin I will get the result:

dependencies {
  api(libs.analytics)
  implementation(libs.turbine)
  implementation(projects.events)
}

Which means it does not force the extra empty line between the two items if they already were sorted and did not have a line between them.

We for example were already maintaining by hand the alphabetical order for our modules, which means that a bunch of them are considered already sorted and this plugin does not go in to adjust them to make them look exactly like it does with all the other ones that it does in fact sort.

[autonomousapps]

Thanks for the issue. Would you consider this a bug or a feature request? I'm not sure of the best resolution. The whitespace is only aesthetic. It is quite literally ignored by the parser. The sorter tries to avoid unnecessary work, so if it detects an already-sorted script, it moves on.

I'm mentally weighing the pros and cons of adding a flag around the concept of "preserving whitespace" or whatever, vs being more opinionated and always adding the whitespace between configuration types. I'd like to solicit feedback from users here.

[StylianosGakis]

Hmm good question, I don't think I would very confidently say that this is a bug. My main concern with this was more or less that let's say we introduce this plugin, devs start seeing some files have it one way, and some have it the other, and they end up being either confused about how they should be doing it, or confused that they themselves might be doing something wrong.

But all things considered, I don't feel like this is breaking anyone, I'd say this is a feature request, and maybe not one that should be prioritized at all, until too many people mention it, or something adjacent to this needs to be changed anyway, and in the meantime this gets fixed too.

[StylianosGakis]

Hmm hit this once again, with slight different context here.

There was a block that looked like this

  implementation(libs.androidx.a)
  implementation(libs.androidx.b)
  implementation(libs.androidx.c)
  implementation(libs.androidx.d)

  testImplementation(libs.assertK)
  testImplementation(libs.junit)

Then I wanted to remove dependency libs.androidx.c from everywhere, so I did a quick search and replace of implementation(libs.androidx.c) with an empty string, thinking I will just run this plugin afterwards to fix it.

I ended up with this then

  implementation(libs.androidx.a)
  implementation(libs.androidx.b)

  implementation(libs.androidx.d)

  testImplementation(libs.assertK)
  testImplementation(libs.junit)

Which now means that there's an empty space between "implementation" and "testImplementation" which is good, but now I am also having an arbitrary empty space in the implemantation block.

Just wanted to throw this example out here too, in case you feel like this one is something that is more important than the one I explained before.

[JakeWharton]

For me, spaces are semantic. They group dependencies which are related to each other (as in the androidx example above). Sometimes this even spans configurations. For example, I usually keep the Dagger runtime and kapt declaration together in their own group.

When switching to a sorted representation where both the configurations and their contents are now sorted, I do not think it makes sense to preserve spaces at all. The meaning is now lost, and I want the normalized behavior OP seeks, too.