Why it was deprecated please? <https://kotlinlang....

# multiplatform

[Tomáš Procházka]

Why it was deprecated please?
https://kotlinlang.org/docs/multiplatform/whats-new-compose-110.html#deprecated-dependency-aliases
It is one of the most time saving feature, there.
You don't need to thing about all the possible KMM libraries, its maven coordinates, you just update the compose plugin and you have everything available, you can just use what you need 😞

[Coty Saxman]

While that saved time in some cases, it completely broke projects in other cases.

Dropping those aliases allowed them to split the versioning of the individual libraries.

In the old system, I often encountered situations where the latest version of some major library has a dependency on a certain version of a compose component, blocking me from upgrading to the latest compose version... Especially for working with alpha/beta/RC versions, it wasn't a great system.

[Tomáš Procházka]

I agree that splitting versions is good for developers.
Release bunch of libraries in one time is complicated.
For regular usage, unless you are working with beta/alpha it was likely simplification.

What about to use published version catalog like this?
https://ktor.io/docs/whats-new-320.html#published-version-catalog

[efemoney]

I have to echo that it wasn’t ‘_the best’_ system and ended up doing some harm for all its good.

> You don’t need to thing about all the possible KMM libraries, its maven coordinates, you just update the compose plugin and you have everything available
Thats considered an exception and not the norm. Out of the box Gradle does not work this way and so you have fragmentation where part of your dependencies are coming from VC & the rest are coming from some bespoke system like this. If you have more of these in your build (for example spring dependency management) it starts becoming unwieldy.
I will always favor idiomatic APIs because they simplify and move the ecosystem forward. Its way easier to reason about when there is only one way to do things.

“Hey where is this dependency coming from? Okay let me check the version catalog. Ah there it is!”
c’est finit!

I think that every build author should at a minimum consciously manage dependencies (via version catalogs) because its one of the most important parts of your build, you really shouldnt be outsourcing its management.

Also with those APIs you lose out on normal gradle APIs that are supported everywhere like version catalogs, you also lose out on improvements made to dependency declaration APIs for both build & plugin authors (viz DependencyCollector) and, lastly, the moment your use case requires you being in a different context, youre automatically stumped and need to fall back to version catalogs & now you have two sources of truth.

[Tomáš Procházka]

> “Hey where is this dependency coming from? Okay let me check the version catalog. Ah there it is!”
> c’est finit!
This will never work, because as you said every library in the project has dependency on different version, we have ususally more than 100-200 libraries in every project, so catalog is always just about our direct dependencies.