-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile to WasmJs #10
Comments
I think supporting Wasm is a great idea but at the same time it may force me to bump up my minimum Kotlin version requirements quite a bit -- currently I support 1.6+ but wasm wasn't even alpha until 1.8.20 -- so I may need to step a little carefully here. (I wish it was as straightforward as just adding the wasm target to the build gradle file) In the past I've tried to use a more recent version of the Kotlin compiler but set compatibility versions to older values, but that didn't work -- when I actually tried to load the library in a test project I got a binary incompatibility error due to it using a more recent version of classes from the stdlib -- but maybe this was user error on my part and there is a way to actually accomplish what I want? Anyway I'll play around with this. If I can use Kotlin 1.8.20 to generate an artifact that can still be consumed by Wasm projects using the latest version, today, then that would just bump Truthish minimum requirements up to 1.7+, which isn't bad in 2025. |
So initial tests look like adding Wasm support works but I will need to bump up the Kotlin version from 1.7.2x to 1.9.2x. This would mean (according to my understanding) changing compatibility for other targets from 1.6+ to Kotlin 1.8+. I have verified locally this produces an artifact I can consume with a test project I created using latest Kotlin 2.1.0. Honestly, Kotlin 1.8+ is probably not be that bad. Although I'd feel a lot more confident if I could customize this per target -- that is, if there was a way to have jvm projects allow 1.6+ and only restrict Wasm projects from requiring 1.8+ (which they would need to anyway because Wasm wasn't available until 1.8.20!). I am slightly worried that Wasm is still alpha as of today (although it's getting close to beta status). For example, let's say I make the sacrifice and bump Truthish up to 1.8+ just for Wasm, and then at KotlinConf this year they say "Hey Wasm is beta now but you have to use Kotlin 2.2 to compile it." Very unlikely, but that would be a big oof. I'm going to ping the multiplatform and Wasm Kotlin slack channels today and see if I can navigate this better than I have been. |
Also, clean up our build script approach while we're at it. Instead of forcing myself to stay on an old version of the multiplatform plugin (and its associated older compiler), now we use the latest version of the multiplatform plugin but: 1) set the language and api versions to control output compatibility 2) add an explicit dependency on an older version of the stdlib (otherwise, even if our generated bytecode is for an older version, we might include stdlib bytecode built with a newer compiler) Fixes #10
OK, I think this is done. I'd be grateful if you could try using truthish The Kotlin Slack actually opened my eyes to a better way to structure my build script, and applying their advice was painless. I feel a lot better about the setup now. Thanks for filing this bug! |
Also, clean up our build script approach while we're at it. Instead of forcing myself to stay on an old version of the multiplatform plugin (and its associated older compiler), now we use the latest version of the multiplatform plugin but: 1) set the language and api versions to control output compatibility 2) add an explicit dependency on an older version of the stdlib (otherwise, even if our generated bytecode is for an older version, we might include stdlib bytecode built with a newer compiler) Fixes #10
@bitspittle sure! I'll try it out in a few hours. |
I've tried, but |
Also, clean up our build script approach while we're at it. Instead of forcing myself to stay on an old version of the multiplatform plugin (and its associated older compiler), now we use the latest version of the multiplatform plugin but: 1) set the language and api versions to control output compatibility 2) add an explicit dependency on an older version of the stdlib (otherwise, even if our generated bytecode is for an older version, we might include stdlib bytecode built with a newer compiler) Fixes #10
Sorry! Try again now. I confirmed this time 100% that I published the artifacts: https://s01.oss.sonatype.org/content/repositories/snapshots/com/varabyte/truthish/truthish-wasm-js/ Not sure what happened the first time -- probably I was just doing too much at once and reverted some local changes accidentally before committing to github. I was sure I had updated the CI workflow to generate wasm artifacts, but when I just went to check, the expected gradle command weren't there. Now they are! |
Let me know if you're able to confirm that 1.0.3-SNAPSHOT is working for you! I'll probably push out a 1.0.3 version in the near future if so. |
@bitspittle it does find the dependency! I don't know if it works, as I also need the Linux Arm64 target - could you please implement that as well? |
Hopefully that works. 🤞 |
@bitspittle it does work! |
No description provided.
The text was updated successfully, but these errors were encountered: