is `internal` modifier good enough reason, to make...

# gradle

[Peter]

is internal modifier good enough reason, to make a Kotlin module 🤔 I have a bunch of packages, that would benefit from that modifier, but there are not many classes in there.

[CLOVIS]

If those packages fit in a greater unit, yes, definitely. Modules also have the benefit of faster incremental compilation, and they can each define their own dependencies, so you can control the visibility of external dependencies as well.

[Peter]

Should I be worried about flat compile time cost, that is added just by adding an empty module for example?

[CLOVIS]

Short answer: no.

Situation 1: you have a single enormous module.
• You edit a class.
• The entire module is recompiled.
Situation 2: you have two modules :a and :b , with :b depending on :a .
• You edit a class in :b .
• :a hasn't changed, so only :b is recompiled.
So, apart from the very first build when you clone the project, it's usually faster.

[CLOVIS]

(the real world is a bit more complicated because the Kotlin compiler is able to do incremental compilation in a single module)
(also, compilation is not the only thing that happens, and Gradle can execute the other things in parallel (e.g. publish your modules, run tests…))

[Casey Brooks]

Honestly, in my experience the biggest penalty for additional Gradle modules is from the configuration time, not from compilation. But the Gradle Configuration Cache eliminates that to an incredible degree, so there’s really not much of a build performance penalty anymore for adding new modules when using the configuration cache

[CLOVIS]

(and if you can't enable the configuration cache, configuration-on-demand is almost as good and less risky)

[Peter]

ok, thank you for explaining guys!