Use ArrayBufferLike instead of ArrayBuffer for reading/writing bytes

[hassankhan]

Prior to using ArrayBufferLike, TypeScript compilation errors in the generated output would occur:

src/generated/foobar.ts:1133:25 - error TS2345: Argument of type '(value: ArrayBuffer) => string' is not assignable to parameter of type 'StringLifter'.
  Types of parameters 'value' and 'bytes' are incompatible.
    Type 'Uint8Array<ArrayBufferLike>' is missing the following properties from type 'ArrayBuffer': maxByteLength, resizable, resize, detached, and 2 more.

Unfortunately, due to merging #197, these legitimate errors were also hidden. Ideally, we should investigate why the generated output has compilation issues and resolve them, and then revert #197.

[jhugman]

Ideally, we should investigate why the generated output has compilation issues and resolve them, and then revert #197.

I am in favour of reverting #197. I don't think the library is yet mature enough to turn off typescript checking for generated code. If we would absolutely want to support turning it off, then we should have the user opt-out by adding something to the uniffi.toml config file.

[hassankhan]

@jhugman I'm in favour of reverting it too, for now (or as you said, make it configurable)

With regards to this specific PR though, is there anything else you'd like to see?

[jhugman]

Sorry, my mistake.

I think switching type-checking back on in this PR, and fixing the resulting errors would be useful. If I understand your comment #0 correctly, this issue is fixing a tsc compile error.

I'm really sorry, I'm afk until 6 January, so can't really check out your PR and poke at it.

I'm going to ask @Johennes or @zzorba to have a look with you.

[hassankhan]

If its all the same to you, I'd prefer to make a separate PR reverting #197, keep this PR as-is to fix this one specific class of TypeScript compilation errors, and make separate PRs for the other errors as I can get to them.

[Johennes]

I haven't observed these error myself so far. I suspect they require the consumer to use a certain minimum TS version?

Would it be possible to set up a test case that exposes the failure and verifies the fix?

[jhugman]

I'm sorry to step on your toes @Johennes .

Looking at this PR, it seems harmless, and only part of @hassankhan 's larger #198.

readArrayBuffer and writeArrayBuffer are only used internally, and not exposed to user space (and so definitely non-trivial to test).

The writeArrayBuffer is only used in FfiConverterString and we can guarantee that this only gets called with an ArrayBuffer.

readArrayBuffer is used in the FfiConverterArrayBuffer, and we can definitely say an ArrayBuffer is returned. We test this in test_coverall2.ts. I am confused why FfiConverterArrayBuffer.read is still compiling, but that is more down to my lack of typescript understanding than anything.

@Johennes What say we approve this, so @hassankhan can regain some of the excellent momentum he had before the break?

[Johennes]

Ah, ok. This sounds totally fine then. Sorry, I didn't dig into the usages myself. I was just being overly cautious because of the prior TS breakage we had. 😅