compose-markdown is too opinionated

[tadfisher]

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.

[halilozercan]

You are definitely right and getting rid of these dependencies is on the list of priorities before the eventual stable release.