yoxjames
I want to start off saying that this is a really cool and interesting project and I think a KMP based syntax highlighter is an awesome idea! I am excited to use it for something I am working on. However, I need to recommend a reversion of a recently added change. `getHighlightsAsync(...)` should be removed from this project along with the dependency on kotlinx-coroutines. This dependency is a **massive** penalty for bundle sizes and for targets like Javascript this could make or break usability of a project. I realize this might be somewhat difficult now at version 1.0.0 (I am proposing a binary incompatible change). If I am writing Kotlin and am fine with the dependency I am free to still use coroutines of course: ```kotlin runBlocking { val highlights = Highlights.Builder() .code(sampleClass) .theme(SyntaxThemes.monokai()) .language(SyntaxLanguage.JAVA) .build() val asncResult = async { val highlights = Highlights.default().run { setCode("public class ExampleClass {}") getHighlights() } } //..... (some time later) asyncResult.await() } ``` I could use a try/catch (or Supervisor Job or CoroutineExceptionHandler) for errors getting what the callback provided. The only piece that would be missing is that I cannot utilize cooperative cancellation between `getCodeStructure()` and `constructHighlights(...)` since `constructHighlights(...)` is private. If that was not the case, I would be able to use something like `ensureActive()` like you did in my callsite example. Realistically I am unsure how big of a problem that is (it wouldn't be for my use case but others may disagree). Alternatively `getHighlights(...)` could have an overload (or default param) to take a `CodeStructure` object allowing callers to implement the exact same cooperative cancellation from the outside. I could also wrap this in something like a `Future` on JVM or `Promise` on a JS target without bringing in any new dependencies if I was concerned with bundle size. I don't think this library should take an opinion on async processing and simply let the caller deal with that however they wish. Javascript users might use Promises, Java users Futures, etc. I get that this is simply a convenience function that can be ignored, but it's really the dependency I want to highlight. As a library developer, I care a lot about transitive dependencies and I don't think it's safe to assume that everyone who uses this also has kotlinx-coroutines in their dependency graph or wants to add it.