@EpicSquid why the removal of @JsExport, is that not necessary for the js library? I am a bit uncertain with the removal though :)

It's only necessary if someone is using the JS library from JS. In kotlin it works fine.

My build only worked with the wasm component when the JS Export tag was removed which was true in the previous branch and, as far as I understand, they aren't necessary anyway.

If it's a key requirement for this to work from JS then I can take another look and see why it might be happening, could be a shared source set issue since the js exports specifically work differently with wasm.

@EpicSquid my team is currently checking than out but I fear that we need the @JsExport for our solid.js library to work as we use the data classes in typescript. Maybe there is an option to define the classes or the files in the build.gradle.

Oh that's very fair using it with solid, hadn't thought of that.

I have an idea I'll try in a day or 2 to fix this.

This should fix the issue. The core problem is that on JS @JsExport works on classes, but on wasm it doesn't. Given that the JS client already exists we can leverage that and put all the JsExport annotations in the JS project only, and have mappers on the kotlin side to translate between as needed.

Looks promising to me, I think we can merge that and have a proper 4.1.0 with official wasm support. Would favor a gentle review by @Khartris or @nvima.

@EpicSquid seems that there exist some errors in the code, sry I have to manually start the build & test action https://github.com/Liftric/cognito-idp/actions/runs/18924710132/job/54168680728

Tests fixed, should be good now

What's the chance you can send me the error file that is generated from the runner? I can't replicate it locally as I don't have the secrets to test with so I can't tell what the issue is

What's the chance you can send me the error file that is generated from the runner? I can't replicate it locally as I don't have the secrets to test with so I can't tell what the issue is

When I run your branch here in GitHub Actions, our secrets are ignored.
However, you can run the tests yourself if you provide a client ID and region:

region= clientId= ./gradlew build test jsTest

I received these error messages locally when running the test:

e: file:///home/jens/work/cognito-idp-epic/src/wasmJsTest/kotlin/idp/IdentityProviderClientTests.kt:3:27 Unresolved reference 'runBlocking'.
e: file:///home/jens/work/cognito-idp-epic/src/wasmJsTest/kotlin/idp/IdentityProviderClientTests.kt:7:12 The 'expect' and the 'actual' declarations are incompatible.
  expect: public final expect fun runTest(block: suspend () -> Unit): Unit
  actual: public final actual fun runTest(block: suspend () -> Unit): <ERROR TYPE REF: Unresolved name: runBlocking>
  reason: the return types are different
e: file:///home/jens/work/cognito-idp-epic/src/wasmJsTest/kotlin/idp/IdentityProviderClientTests.kt:7:49 Unresolved reference 'runBlocking'.
e: file:///home/jens/work/cognito-idp-epic/src/wasmJsTest/kotlin/idp/IdentityProviderClientTests.kt:8:11 Suspend function 'suspend fun invoke(): Unit' can only be called from a coroutine or another suspend function.

I'm not very familiar with this project, but I tried a few things to resolve the Errors in src/wasmJsTest/kotlin/idp/IdentityProviderClientTests.kt and rerun the Tests and got these Errors:

    NotImplementedError: An operation is not implemented: Not yet implemented

I guess it is because of this part, the commonTests seems to need the Base64 decode implementation for wasm src/wasmJsMain/kotlin/com/liftric/cognito/idp/jwt/Base64.kt

internal actual class Base64 {
   actual companion object {
       actual fun decode(input: String): String? {
           TODO("Not yet implemented")
       }
   }
}