Skip to content
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

Open
Laxystem opened this issue Jan 18, 2025 · 10 comments
Open

Compile to WasmJs #10

Laxystem opened this issue Jan 18, 2025 · 10 comments

Comments

@Laxystem
Copy link

No description provided.

@bitspittle
Copy link
Collaborator

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.

@bitspittle
Copy link
Collaborator

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.

bitspittle added a commit that referenced this issue Jan 19, 2025
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
Copy link
Collaborator

OK, I think this is done.

I'd be grateful if you could try using truthish 1.0.3-SNAPSHOT in your project. (Please see https://github.com/varabyte/truthish?tab=readme-ov-file#testing-snapshots for how to add a maven repository that provides the snapshot)

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!

bitspittle added a commit that referenced this issue Jan 19, 2025
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
@Laxystem
Copy link
Author

Laxystem commented Jan 19, 2025

@bitspittle sure! I'll try it out in a few hours.

@Laxystem
Copy link
Author

I've tried, but truthish-wasm-js is not available on that repository.

bitspittle added a commit that referenced this issue Jan 19, 2025
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
Copy link
Collaborator

I've tried, but truthish-wasm-js is not available on that repository.

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!

@bitspittle
Copy link
Collaborator

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.

@Laxystem
Copy link
Author

@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?

@bitspittle
Copy link
Collaborator

@Laxystem
Copy link
Author

@bitspittle it does work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants