halilozercan
compose-markdown is too opinionated
We use a non-Material design system with compose-richtext, and the 1.0 series is pulling in a large number of dependencies that we don't need. We don't use image or HTML features, as we already have a parsed AST using JetBrains/markdown; we just call the appropriate RichTextScope function with data from our AST.
In particular, for our app, just moving from richtext-ui:0.2.0 to richtext-markdown:1.0.0-alpha01 adds the following dependencies:
-
androidx.compose.material3:material3 -
androidx.compose:compose-bom -
androidx.constraintlayout:constraintlayout-solver -
androidx.constraintlayout:constraintlayout -
androidx.customview:customview -
androidx.drawerlayout:drawerlayout -
androidx.dynamicanimation:dynamicanimation -
androidx.legacy:legacy-support-core-ui -
androidx.profileinstaller:profileinstaller -
androidx.recyclerview:recyclerview -
com.google.accompanist:accompanist-drawablepainter -
com.google.android.material:material -
com.google.errorprone:error_prone_annotations -
com.google.errorprone:error_prone_parent -
io.coil-kt:coil-base -
io.coil-kt:coil-compose-base -
io.coil-kt:coil-compose -
io.coil-kt:coil -
io.github.aghajari:AnnotatedText -
org.commonmark:commonmark-ext-autolink -
org.commonmark:commonmark-ext-gfm-strikethrough -
org.commonmark:commonmark-ext-gfm-tables -
org.commonmark:commonmark-parent -
org.commonmark:commonmark -
org.nibor.autolink:autolink
I would appreciate being able to use richtext-markdown just for rendering an AST, and to pass in our own rendering functions for autolinks, HTML, and images. If this is out of scope for this library, that's fine; we can vendor in RichTextScope and friends.
You are definitely right and getting rid of these dependencies is on the list of priorities before the eventual stable release.
