A modern programming language that makes developers happier.

kotlinlang

:wave: Q: How you manage growing setting.gradle.(kts) file in high modularised app?
I started with writing a custom-plugin, which will include sub-projects, but soon realised - traversing on the dir tree, and adding the modules is not performant as compared to adding them manually in settings.gradle.(kts) file.

yeah, it's a good correction, still it confirms my worry, if make it CC safe, but essentially break CC because every single file becomes CC input

Well, you can do some restrictions, like only checking 3 dirs deep and directly checking whether a build script exists instead of listing all files, the only those you check become input and also just their existence, not content. (Will if they are build scripts their content will become input anyway)

Not, that i have tried - after reading the <https://docs.gradle.org/current/userguide/kotlin_dsl.html#sec:scripts|doc>
```Name settings scripts (or any script that is backed by a Gradle Settings object) according to the pattern *.settings.gradle.kts — this includes script plugins that are applied from settings scripts```

I believe, a different settings script plugin can be created just for including sub-projects, limit main settings.gradle.kts limited to other configurations like pluginManagement, depenDencyResolution etc..

Besides that script plugins per-se are highly discouraged (unless you talk about pre-compiled script plugins), I don't know how that would improve anything.

I think, it would just separate few pieces in different files, *.settings.gradle.kts focused on includes(), settings.gradle.kts on configuration. Also, opening up a possibility of linking those files to separate code-owners on github to be notified on, without much noise.

Definitely, pre-compiled script plugins should be preferred.

Yeah, there might also be an existing settings plugin that does such auto-discovery that you simply could use.