https://kotlinlang.org logo
#amper
Title
# amper
w

Waldemar Kornewald

11/13/2023, 12:17 PM
Finally, it should be possible to set the default list of lib platforms in the root build script instead of having to repeat that list in every module. Like suggested in the announcement thread, the root build script should be the preferred place for many configuration options. Per-module configs should ideally be the exception.
a

Anton Prokhorov

11/13/2023, 2:33 PM
Do templates solve this issue?
w

Waldemar Kornewald

11/13/2023, 2:52 PM
Templates require explicit mentioning in every module. This means every developer has to know about that convention and copy-paste the same apply section everywhere. They also have to know which of the templates is the right one. Usually with Gradle you'd instead use the subprojects block in the root build script to configure all modules and define a convention like
project.name.startswith("app-")
or match on the path to apply some config to all modules within a subfolder (when you have two or more levels). This is a convention that everyone can see and follow at first glance (it's self-documenting) and it requires no copy-paste with 50 modules. That's similar to
src@jvm
which is also self-documenting because it's based on file/directory naming. Templates may have their uses, but we have quite complicated and large projects with many different teams and the convention based solution works really well and helps giving you a better overview because you open just one file and see all the modules e.g. that export an XCFramework or have something else in common. This overview is missing with the templates solution. Also creating templates has its own friction. Most developers just won't do it. They'll be used to editing individual module files and start copy-paste solutions. Forcing people to apply rules from the root makes them think in better generalizations because the friction is minimal and the better overview helps with generalizing.
As a crazy thought experiment, what if we had templates in the root folder that could be applied to child module name patterns or other properties (e.g. the product or platform)?
Basically, my suggestion is to have a declarative way to match modules and apply rules to them.
a

Anton Prokhorov

11/13/2023, 5:38 PM
Fair enough, good point, thanks, we will consider this feedback during our future experiments