I checked that Compose Desktop dependency is exposing the ma

Question

I checked that Compose Desktop dependency is exposing the material dependency which should be unnecessary if you are not using Material Is it a requirement or it can be changed from `api` to `implementation`

Javier · Answer

Javier · Answer

``` commonMain dependencies implementation libs kotlinStdlibCommon implementation project compose ui ui util api project compose foundation foundation api project compose material material api project compose runtime runtime api project compose ui ui api project compose ui ui tooling preview ```

Javier · Answer

it is exposing this theme which IMO should be in its own artifact like material does in Android <https android googlesource com platform frameworks support + refs heads androidx main compose desktop desktop src jvmMain kotlin androidx compose desktop DesktopTheme jvm kt|https android googlesource com platform frameworks support + refs heads androidx main c Main kotlin androidx compose desktop DesktopTheme jvm kt>

Igor Demin · Answer

Yes it is one of the things which should be changed in <https github com JetBrains compose jb issues 497|my opinion> it is not trivial as replacing `api` with `implementation` The purpose of `desktop` was aggregating all Compose modules and it was introduced at the very beginning of the CfD But as you mention not everyone needs material also not everyone need foundation The current workaround is to exclude dependency explicitly

Igor Demin · Answer

gt it is exposing this theme which IMO should be in its own artifact like material does in Android DesktopTheme will be deprecated in a new build so this module will no longer have usable classes functions

Javier · Answer

but the idea is removing both no DesktopMaterialTheme and DesktopTheme

Javier · Answer

then I can just wait until this module is deleted

Javier · Answer

thank you for the detailed info slightly smiling face

Igor Demin · Answer

DesktopMaterialTheme will be replaced by `MaterialTheme` DesktopTheme by `CompositionLocalProvider LocalScrollbarStyle provides `

Igor Demin · Answer

gt then I can just wait until this module is deleted It maybe not in the near future because it is not trivial to get rid of it currently `desktop` knows what version of skiko should be used when we use `desktop currentOs` we actually use `desktop windows` or `desktop linux` we want to keep one liner dependency for users which use only `material` module <https github com JetBrains compose jb issues 497|the issue> suggests how we can fix it

Javier · Answer

yeah I have read it entirely like this one too ```Theoretically we can still ship separate artifacts for each platform mac arm64 mac x64 win64 linux64 and make MPP plugin resolve platform automatically ```