Add support for Wasm

[SalomonBrys]

Please deploy artifact for the wasmJs & wasmWasi targets.

[ShayOinif]

I would love that too if it is possible.
RIght now on compose multiplatform I use Canvas on JS target to make my UI just because of no wasJs target :/

[sgammon]

Even if it is just annotations, so we can annotate classes in commonMain with wasm targets

[Mr3zee]

@sgammon can you please elaborate on your comment? What annotations are you talking about?

[sgammon]

@Mr3zee Sorry, I mean annotations or interfaces. Things that can safely be included in a common target, so that we can at least create our RPC interfaces in a common target, even if we can't implement them there yet.

[Mr3zee]

I see, thank you
I'll if this is worth to do now, or it would be easier just to support WASM fully

[CheeseTastisch]

@Mr3zee when can we plan with wasm support?

[sylvain-barrepersyn]

If I understand correctly, this feature will be delivered in the next version of kotlinx-rpc. Do you have any idea when ?

[Mr3zee]

No ETA for now

[sgammon]

@Mr3zee Could a WASM target be added which is functionally empty? Or even just has kotlinx.rpc.RPC defined as an interface? That would be sufficient for our needs for now.

Because KotlinX RPC does not ship a WASM target, we cannot use KotlinX RPC in any source set which ships for WASM, or which ultimately is depended on downstream by a source set for WASM, whether or not those source sets make use of RPC.

[sgammon]

I would humbly ask that you reconsider because KotlinX RPC is the only KotlinX library we cannot use due to this reason

[sylvain-barrepersyn]

I very agree, just to compile projet and permit to have a shared module (multiplatform one) in projects which have the goal to target WASM in the future. It can be useful to juste have an empty dependency compliant to this target.

[Mr3zee]

WASI is blocked by oshai/kotlin-logging#433, wasmJs is WIP

[sgammon]

I would actually be surprised to find oshai/kotlin-logging as a dependency to RPC...

[Mr3zee]

@sgammon It is a dependency for the kRPC protocol implementation
For core declarations both WASMs will be added right away

Necessity for the logging dependency will be assessed before going stable

[sgammon]

@Mr3zee Am I correct in my assumption that this is the only place a KotlinX library depends on something outside of kotlin-stdlib and other KotlinX libraries?

[Mr3zee]

@sgammon technically, yes (though I'm not sure about all of the other kotlinx libs).

But there is a little more to that. Our core module depends only on atomicfu, coroutines and serialization. Core module and codegen plugins make the foundation of the library, so being dependent on core libs is only logical.

Then kRPC (and other modules in work) is an implementation of the library foundation, more complex than core itself, and requires external dependencies. And while logging is a debatable topic here, and it may happen, that kRPC will also be dependent only on core libs, for gRPC, for example, it surely will not be the case, as we will use existing platform specific libs to provide this integration. Implementing gRPC protocol from scratch is not what we want to do.

[sgammon]

@Mr3zee Thank you so much for shipping this one!