Replies: 1 comment
-
I would include them, and I also in general endorse using sbt-explicit-versions to have a CI check that the versions you declare are actually what you use. It automatically filters out fully transitive dependencies that never appear in your own code, but if you import fro a jar, it forces you to list that as a dependency |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello everyone:
In my experimentation with the Diamond Architecture, I have been analyzing the dependency trees of the various modules that the project currently has. One of my goals is to explore the benefits of keeping the dependencies of each module to the bare minimum.
The first thing that I noticed is that the wide spread usage of
commonDependencies
actually makes the dependency trees very hard to read (they are convoluted). I have come to believe that this kind of usage might be an anti-pattern.So my approach has shifted towards include dependencies in a per-module basis.
Taking this as a starting point, here it comes my question to you all. If a module has a dependency on A and A has it on B. Should I add B explicitly to the module as dependency?
The concrete case can be seen in the dependency tree of the module
02-c-config
.On one hand, this is the build.sbt and the dependency tree for the were there is only one explicit dependency and the rest are transitive:
Like this, the version used are:
cats-effect-kernel_3:3.4.6
cats-core_3:2.9.0
On the other hand, this is the build.sbt and the dependency tree with all the explicit dependencies:
Like this, the version used are:
cats-effect-kernel_3:3.4.10
>cats-effect-kernel_3:3.4.6
cats-core_3:2.9.0
= cats-core_3:2.9.0com.chuusai:shapeless_2.13:2.3.9
- not in prior treeThe first approach (relaying on transitive dependencies) offers the following benefits:
Simplicity and Reduced Maintenance: Keep the module's dependencies minimal and avoid adding unnecessary dependencies to the codebase. This simplifies the project's structure and reduces the maintenance overhead of managing direct dependencies.
Dependency Management: Delegate the responsibility of managing transitive libraries to sbt.
Efficient Resource Utilization: Reduce the overall size of the module and potentially optimize resource consumption.
Easier Updates and Compatibility: When
ciris
updates its version or includes a newer version ofcats
, we automatically benefit from these updates without explicitly managing and updating the direct dependency oncats
. This can simplify the process of keeping the module up to date and ensure compatibility with the latest versions ofciris
.Avoiding Version Conflicts: Leverage sbt's ability to resolve conflicts between different versions
cats
. Sbt will select a compatible version based on the requirements ofciris
and other dependencies, reducing the risk of version conflicts in your module.The second approach (explicit dependencies) offers the following benefits:
Explicitness and Clarity: It is clear and explicit that the module depends on
cats
. This helps in understanding the module's dependencies at a glance, making it easier for us to comprehend and maintain the codebase.Reduced Dependency Chain: By directly including the dependency on
cats
, we eliminate one level of transitive dependency, simplifying the module's dependency chain. This can help reduce potential issues related to transitive dependencies, such as dependency conflicts or unexpected behavior caused by changes in intermediate dependencies.Stability and Control: Relying on transitive dependencies can introduce unexpected changes or updates to the module without explicit control. Including a direct dependency on
cats
ensures that any changes or updates tociris
are explicitly evaluated and controlled, reducing the risk of unexpected behavior or breaking changes in the module.So, what do you chose?
6 votes ·
Beta Was this translation helpful? Give feedback.
All reactions