Cannot assign Uint8Array type to Uint8Array variable created with constructor

[achingbrain]

🔎 Search Terms

uint8array

🕗 Version & Regression Information

• This changed between versions 5.7.3 and 5.6.3
• This changed in commit or PR Make typed arrays generic over ArrayBufferLike #59417
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Uint8Arrays
• I was unable to test this on prior versions because Uint8Array was not generic before 5.7.3

⏯ Playground Link

https://www.typescriptlang.org/play/?target=11&ts=5.8.3#code/GYVwdgxgLglg9mABAcwKZQIICcuIBQCUAXIgKoxhQAc2WAhgJ6IDeAUIoluiFkmKgHcyFarUZ4ADAVYBfVqwA26RHRyIAvIn5DylGjnFTWq3JrSYcheUqgqcAJhK7RBppu3C9YhpOkn7GijotFZAA

💻 Code

function getArr (): Uint8Array {
  return new Uint8Array(0)
}

let arr = new Uint8Array(0)
arr = getArr() // fails compilation with TS2322

let arr2: Uint8Array = new Uint8Array(0)
arr2 = getArr() // this is fine

🙁 Actual behavior

TS2322 is thrown during compilation.

🙂 Expected behavior

I should be able to assign a value of type Uint8Array to a variable initialised with the Uint8Array constructor without specifying extra generics or types.

Additional information about the issue

The compilation error is:

Type 'Uint8Array<ArrayBufferLike>' is not assignable to type 'Uint8Array<ArrayBuffer>'.
  Type 'ArrayBufferLike' is not assignable to type 'ArrayBuffer'.
    Type 'SharedArrayBuffer' is missing the following properties from type 'ArrayBuffer': resizable, resize, detached, transfer, transferToFixedLength(2322)

[snarbles2]

I'm filling in the inferred types/generic arguments to make what's happening more obvious.

// <ArrayBufferLike> is the default generic argument
function getArr (): Uint8Array<ArrayBufferLike> { 
  return new Uint8Array(0)
}

// <ArrayBuffer> is the generic argument applied with this
// constructor overload
let arr: Uint8Array<ArrayBuffer> = new Uint8Array(0)
// Assigning Uint8Array<ArrayBufferLike> to Uint8Array<ArrayBuffer>
arr = getArr()

// <ArrayBufferLike> is the default generic argument
let arr2: Uint8Array<ArrayBufferLike> = new Uint8Array(0)
// Assigning Uint8Array<ArrayBufferLike> to Uint8Array<ArrayBufferLike>
arr2 = getArr()

I agree it's worthy of a double-take but I couldn't say what could be changed here that would fix this without causing other problems.

[Renegade334]

This is one of the inevitable consequences of #59417. This was mini-discussed at DefinitelyTyped/DefinitelyTyped#72056 (comment) and DefinitelyTyped/DefinitelyTyped#72056 (comment), with the verdict being "intended behaviour".

The flip-side is that this is very easy to work around by explicitly typing the variable, as you've identified.

[achingbrain]

This has started to affect Blob creation in the latest 5.9.x release:

function getArr (): Uint8Array {
  return new Uint8Array(0)
}

const blob = new Blob([getArr()])

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 missing the following properties from type 'ArrayBuffer': resizable, resize, detached, transfer, transferToFixedLength(2322)

It compiles without issue under 5.8.3.

[Renegade334]

This has started to affect Blob creation in the latest 5.9.x release

See #62168.

[valadaptive]

This was mentioned in #62168, but that issue was closed so I'm reposting it here with some more context:

@types/node does not allow a type parameter for this:

@types/node has not been updated with the new types for Buffer! For instance, fs.readFile will always return a Buffer<ArrayBuffer> and never a Buffer<SharedArrayBuffer>, but the types do not reflect this. So passing the output of fs.readFile into anything that expects a Buffer<ArrayBuffer> (which is a lot of methods and constructors now) requires an as-cast.

I think you would be getting a lot fewer complaints about this behavior change if you had coordinated to ensure platforms' type definitions were actually updated to work properly.

[Renegade334]

@types/node has not been updated with the new types for Buffer!

These changes are in the pipeline, but need to land in one patch across the entire library so as not to trigger these assignability errors when passing values between the package's own APIs, so are taking a bit of time to put together.