Dependency cleanup #8001
Dependency cleanup #8001
Conversation
| implementation(libs.timber) | ||
|
|
||
| testImplementation(libs.robolectric) | ||
| testImplementation(libs.robolectric.shadows) |
There was a problem hiding this comment.
The API surface of org.robolectric:shadows-framework is part of org.robolectric:robolectric's API surface. We'll never use the shadows framework independently of Robolectric. Why include a direct dependency?
| @@ -3,9 +3,13 @@ plugins { | |||
| } | |||
|
|
|||
| dependencies { | |||
| api(projects.app.core) | |||
There was a problem hiding this comment.
Why make :app:core part of :feature:widget:message-list's API surface? Ideally a feature module would never make any of its dependencies part of its public API.
| implementation(projects.app.ui.legacy) | ||
| implementation(projects.app.core) | ||
| implementation(projects.core.ui.legacy.designsystem) | ||
| implementation(projects.mail.common) |
There was a problem hiding this comment.
It feels like this should be tackled once we actually work on removing the dependency on :app:core. Chances are that will also get rid of the :mail:common dependency. It doesn't feel like adding a direct dependency on :mail:common now while also keeping the :app:core dependency adds any value.
|
|
||
| implementation(libs.preferencex) | ||
| api(libs.preferencex) |
There was a problem hiding this comment.
Why make this particular library an API dependency?
| api(projects.app.core) | ||
| api(projects.app.ui.base) | ||
| api(projects.app.ui.legacy) | ||
| api(projects.mail.common) |
There was a problem hiding this comment.
This dramatically increases the API surface of the feature module. Why?
|
This is a partial change to the dependencies setup and not complete. So there are The rest will be continued when there is more time available. |
|
As this is not crucial at the moment, I'll close this and continue at a later point |
This is a first step to cleanup the project dependencies and declare transient dependencies better.