So, I was trying to come with an example to post in the `U*` types support for `JsExport` (<https://...

# javascript

[Edoardo Luppi]

So, I was trying to come with an example to post in the U* types support for JsExport (https://youtrack.jetbrains.com/issue/KT-51389) and thought to ask one thing before posting it.
Currently to support both the JVM and Node's buffers (Uint8Array) I've defined an expect class with typealiases:

public expect class ZByteArray

public actual typealias ZByteArray = ByteArray
public actual typealias ZByteArray = Uint8Array

The problem with this approach is in common code ZByteArray doesn't have any methods or fields, it's useless.
Is there a way to overcome this limitation?

[Adam S]

for any functionality that you need in commonMain you can add expect extension functions, and then delegate to the actual functionality in the actual targets

expect fun ZByteArray.foo(): String

you might be better off using Okio though? That’s got good multiplatform support for byte arrays

[Edoardo Luppi]

That's what I was thinking too, about extension functions. I guess it's an ok workaround!
Related to Okio or other libraries, I'm trying to keep dependencies to a minimum, possibly zero.
This helps in deploying this library everywhere I need as it's self contained.

[jw]

You can also switch to value classes which give you "member" functions on the common type

[Edoardo Luppi]

There is a bit of trickery with using that ZByteArray tho, like

/**
  * Reads [n] bytes, and advances the read pointer.
  */
 @Suppress("NON_EXPORTABLE_TYPE")
 public fun readBytes(n: Int): ZByteArray

You see that I had to suppress a compiler warning.

@jw interesting, could you make an example, I'm not sure how it would be used in this case