Blob constructor no longer accepts a TypedArray input (ts5.9)

[imirkin]

🔎 Search Terms

Blob, BlobPart, TypedArray

🕗 Version & Regression Information

• This changed between versions 5.8 and 5.9

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.2#code/DYUwLgBAhgTjBcECqBLAdmAHAQTlAnhALwRogDuy6WuMBAFANoC6AlANwBQokARsAHtexUhQgAhQbyawYbdkA

💻 Code

let arr: Uint8Array = new Uint8Array([]);
let blob = new Blob([arr]);

🙁 Actual behavior

Type 'Uint8Array<ArrayBufferLike>' is not assignable to type 'BlobPart'.
  Type 'Uint8Array<ArrayBufferLike>' is not assignable to type 'ArrayBufferView<ArrayBuffer>'.
    Types of property 'buffer' are incompatible.
      Type 'ArrayBufferLike' is not assignable to type 'ArrayBuffer'.
        Type 'SharedArrayBuffer' is not assignable to type 'ArrayBuffer'.
          Types of property '[Symbol.toStringTag]' are incompatible.
            Type '"SharedArrayBuffer"' is not assignable to type '"ArrayBuffer"'.

🙂 Expected behavior

Successful compliation.

Additional information about the issue

This error is covered in https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-9.html#libdts-changes and in #62240.

However I think this is different -- there the advice is to add .buffer to type TypedArray. But I'd argue that the bug is in the Blob constructor specification. https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob says that the constructor should take "An iterable object such as an Array, having ArrayBuffers, TypedArrays, DataViews, Blobs, strings"

While this is precipitated by the changes to ArrayBuffer specification, it seems like the BlobPart should have been changed to compensate.

[Renegade334]

Duplicate of #62168, microsoft/TypeScript-DOM-lib-generator#2113, etc.

If you pass a typed array as a BlobPart, it must be backed by an ArrayBuffer, not a SharedArrayBuffer. This behaviour was added to the libs in TS 5.7 to match the web specification, but it only became observable for most projects in TS 5.9.

For your example, there is now a subtle difference between:

let arr = new Uint8Array([]); // inferred: Uint8Array<ArrayBuffer>
let blob = new Blob([arr]); // works

and

let arr: Uint8Array = new Uint8Array([]); // declared: Uint8Array<ArrayBufferLike>
let blob = new Blob([arr]); // fails: Uint8Array<ArrayBufferLike> can be backed by a SharedArrayBuffer

[imirkin]

I see. So basically every project just needs to run a global

sed 's/Uint8Array/Uint8Array<ArrayBuffer>/g'

(and again for other TypedArray types in use) once ts 5.9 (or 5.7?) is in play if they want things to just work and don't care about SharedArrayBuffer. After re-re-rereading the release notes, I do see that advice in there as well, however it could be called out a bit more clearly.

[alumni]

If you pass a typed array as a BlobPart, it must be backed by an ArrayBuffer, not a SharedArrayBuffer. This behaviour was added to the libs in TS 5.7 to match the web specification, but it only became observable for most projects in TS 5.9.

I'm not sure the difference ArrayBuffer vs SharedArrayBuffer matters for BlobPart in NodeJS, their docs explicitly mention Buffer as a source in the constructor:

<ArrayBuffer>, <TypedArray>, <DataView>, and <Buffer> sources are copied into the 'Blob' and can therefore be safely modified after the 'Blob' is created.

See https://nodejs.org/api/buffer.html#new-bufferblobsources-options.

Also, this works fine in NodeJS, only TS 5.9 prevents it:

const sab = new SharedArrayBuffer(4);
const buffer: Buffer<SharedArrayBuffer> = Buffer.from(sab);
const blob = new Blob([buffer], { type: 'text/plain' });

@imirkin @Renegade334 I think this issue should be reopened, only for BlobPart (and fixed in @types/node).

[Renegade334]

@types/node does not yet provide the same ArrayBufferView divergence for web APIs as @types/web, so if you are in any way affected by this change, it's nothing to do with that package.

[alumni]

Good thing pointing there's differences between node and browsers, I wasn't looking at the file names when I was checking the type definitions.

The Blob constructor defined in @types/node doesn't even have a BlobPart[] as a first parameter, BlobPart only exists in lib.dom.d.ts.

For some reason the DOM types are loaded even though we don't change the libs that @tsconfig/node22 specifies, so both FormData and Blob are using the definitions from lib.dom.d.ts. I don't know yet how the DOM types are getting into the project, but I'll take a look on that. Later edit: it's a triple slash reference in one of our dependencies (@types/jsdom), we'll probably replace it with an alternative.

Thanks :)

[guest271314]

@Renegade334

This behaviour was added to the libs in TS 5.7 to match the web specification

Huh? Kindly cite the Web specification(s) you are referring to. I don't see that in W3C File API or WHATWG Web IDL BufferSource.