https://kotlinlang.org logo
Join Slack
Powered by
I have a question about publishing multiplatform l...
# multiplatform
d
I have a question about publishing multiplatform libraries. Ideally, I want to ensure maximum compatibility for consumers, so I've been using as old a Kotlin compiler to build my artifacts as possible, but the more multiplatform targets I try to add, the more I find myself sacrificing that in order to support this or that one off target. Maybe there's a better way than what I've been doing? I'll put more concrete details into a thread 🧵
The specific project in this case is an assertion library I've been working on for a while (it was how I taught myself multiplatform when it was new!). The code is at the moment 100% in common code. Originally I just targeted JVM and JS but it has since grown to accomodate more targets. You can find my build script here if curious.
Currently, the code is built using Kotlin 1.7.21, which (as I understand) gives it compatibility with projects using 1.6+
Originally I think I was using an even slightly older version, but I had to bump it up when adding support for iOS (since there was, if I recall, a bug in the Multiplatform Plugin for iOS targets that wasn't fixed until 1.7.2x)
Today, a user asked if I could support wasm, which, after some quick local testing, would mean I'd need to use Kotlin 1.9.20, the first version that seems to work.
So now I'm facing a dilemma. Do I support the target, and tell users who have Kotlin 1.6 and Kotlin 1.7 projects that they're out of luck?
Or is there a way actually to use the very very latest Kotlin version and just tell the compiler to generate code that can be consumed by older compilers?
(I tried doing that a while back but I could never get it to work -- every time I tested using something like the Kotlin compatibility setting, I would see that my own library code could be consumed but references to stdlib classes I think would fail as binary incompatible, something like that)
---
I guess, in summary, my question is: Can I rewrite / reorganize my build script in a way that I can add targets over time without forcing me to bump up the compatibility of artifacts I'm producing for other targets? Some things I'm wondering if they could work... • a configuration value I could be setting that I don't know about • a trick where I create many different modules, each with its own build script that only generates a subset of artifacts, each with their own separate Kotlin version used to build them • a super hack where I create multiple build scripts and then, with logic on the CI, rename the one I want to be active as 
build.gradle.kts
How do other projects deal with this? Do they even care? Is Kotlin 1.8+ old enough at this point I shouldn't even be worrying about compatibility for projects using older versions?
e
https://kotlinlang.org/docs/gradle-configure-project.html#dependency-on-the-standard-library you can explicitly declare a dependency on an older kotlin-stdlib
d
Oh, thanks! I'll give that a try
Just an update @ephemient this approach was very simple, worked perfectly, and allowed me to modernize my build scripts. Thanks again!
5 Views
Open in Slack
PreviousNext
Powered by