This message was deleted.

Regarding 2: I think the approach (or variations of it) are fine. There should be no unwanted side effects. I do things like this often.

Personally, I'd avoid this because it's complex code that solves something that I consider a non-problem, and if it breaks, it probably breaks in ugly ways. But that might just be defensive old me.

I agree that this particular solutions looks a bit complex. 🙂 Ideally the projects are not in arbitrary subfolders but only e.g. on one hierarchy level. Then the code can be much simpler. E.g.:

rootDir.listFiles()?.filter { File(it, "build.gradle.kts").exists() }?.forEach { subproject ->
    include(subproject.name)
}

Thanks for all the insights! That’s exactly what I was hoping to hear! In our case, we wanted to be able to have subprojects in nested subdirectories to “group” related subprojects together in a hierarchical way. I agree this may sound complex, perhaps in the future we might reevaluate this decision.

There are also other aspects why this is hard to do right generically. Build scripts don't have to be called

build.gradle.kts

but can also be called

foo.gradle.kts

, projects don't need to have an actual build script, even if there is a build script, it might just be some example project, even if it has a build script it might be a sub-build of a composite build instead of a sub-project, ...

I implemented this exact solution at our organization as the settings.gradle file was a common source of merge conflicts in massive mono repos. I did it the way that Jendrik suggested and wrote a Settings plugin to do this and recursively search the directory structure for any build.gradle or build.gradle.kts files and call Settings.include() on that folder path in the proper format. But the implementation had to take into account things that Jendrik and Vampire both mentioned. Some of our repos were creating Gradle plugins and we have build.gradle files in the src/test/resources folder that we use in our GradleRunner tests, so we had to ensure certain folders are excluded. I feel like the solution is absolutely going to be somewhat custom from org to org and there's no good way for Gradle to do this themselves. The Plugin/Settings API that Gradle currently publishes is the best way to allow organizations to do this simply in a way that fits their needs.