If you add the following declaration to overload the declaration of isArray():

interface ArrayConstructor {
    isArray(arg: ReadonlyArray<any> | any): arg is ReadonlyArray<any>    
}

the post-checked mutable is still narrowed to T[] and the post-checked immutable is narrowed to ReadonlyArray<T> as desired.

I'm not sure if this or similar would be an acceptable addition to the standard typing libraries or not, but you can at least use it yourself.

@jcalz yes, I think these overloads should be in the standard library. There are a few other scenarios where ReadonlyArray isn't accepted where it should be (for example Array.concat).

The same narrowing problem also exists for this check:

if (immutable instanceof Array) {
  const x = immutable; // Any[]  - Should be ReadonlyArray<T>
} 

I'm not sure if there exists a similar workaround for this.

I would probably do this if I wanted a workaround:

interface ReadonlyArrayConstructor  {
    new(arrayLength?: number): ReadonlyArray<any>;
    new <T>(arrayLength: number): ReadonlyArray<T>;
    new <T>(...items: T[]): ReadonlyArray<T>;
    (arrayLength?: number): ReadonlyArray<any>;
    <T>(arrayLength: number): ReadonlyArray<T>;
    <T>(...items: T[]): ReadonlyArray<T>;
    isArray(arg: any): arg is ReadonlyArray<any>;
    readonly prototype: ReadonlyArray<any>;
}
const ReadonlyArray = Array as ReadonlyArrayConstructor;

And then later

if (ReadonlyArray.isArray(immutable)) {
  const x = immutable; // ReadonlyArray<T>
} 
if (immutable instanceof ReadonlyArray) {
  const x = immutable; //  ReadonlyArray<T>
} 

but of course, since at runtime there's no way to tell the difference between ReadonlyArray and Array, you would have to be careful to use the right one in the right places in your code. ¯\_(ツ)_/¯

@vidartf As instanceof works at runtime, I'm not sure that should narrow to ReadonlyArray. You're asking if the runtime representation of that is an array, which is true. So I'd expect it to narrow to Array<T>, not ReadonlyArray<T>.

@jinder I didn't state it explicitly, but my code was meant to be based on yours (same variables and types), so it should already know that it was T | ReadonlyArray<T>. As such, instanceof should narrow it to ReadonlyArray<T>.

What is the best workaround here ?
I just ended up with ugly type assertion:

function g(x: number) {}

function f(x: number | ReadonlyArray<number>) {
    if (!Array.isArray(x)) { 
        g(x as number); // :(
    }
}

I think this is fixed in 3.0.3.

@adrianheine doesn't seem to be for me.

Oh, yeah, I was expecting the code in the original issue to not compile, bu that's not even the issue.

Temporary solution from @aleksey-l (on stackoverflow) until the bug is fixed:

declare global {
    interface ArrayConstructor {
        isArray(arg: ReadonlyArray<any> | any): arg is ReadonlyArray<any>
    }
}

It is not only ReadonlyArray: #33700

Here's a concrete example of ReadonlyArray<string> behaving differently than Array. The !Array.isArray() case fails to eliminate the ReadonlyArray<string> when narrowing.

it should be like this

interface ArrayConstructor {
  isArray(arg: unknown): arg is unknown[] | readonly unknown[];
}

and test it in typescript

const a = ['a', 'b', 'c'];
if (Array.isArray(a)) {
  console.log(a); // a is string[]
} else {
  console.log(a); // a is never
}

const b: readonly string[] = ['1', '2', '3']

if (Array.isArray(b)) {
  console.log(b); // b is readonly string[]
} else {
  console.log(b); // b is never
}

function c(val: string | string[]) {
  if (Array.isArray(val)) {
    console.log(val); // val is string[]
  }
  else {
    console.log(val); // val is string
  }
}

function d(val: string | readonly string[]) {
  if (Array.isArray(val)) {
    console.log(val); // val is readonly string[]
  }
  else {
    console.log(val); // val is string
  }
}

function e(val: string | string[] | readonly string[]) {
  if (Array.isArray(val)) {
    console.log(val); // val is string[] | readonly string[]
  }
  else {
    console.log(val); // val is string
  }
}

Would a PR that adds the appropriate overload to Array.isArray be reasonable at this point? This issue is marked as In Discussion, but I'm not sure what discussion is necessary. This just feels like a mistake in the definition files, which should be an easy fix that any contributor can submit.

Proposed addition to built-in TS libraries:

interface ArrayConstructor {
    isArray(arg: ReadonlyArray<any> | any): arg is ReadonlyArray<any>    
}

Any news here? :|

I do not understand why we cannot accept the solution from @kambing86:

interface ArrayConstructor {
  isArray(arg: unknown): arg is unknown[] | readonly unknown[];
}

Why do we need to use any instead of unknown? When I use isArray() then it loses all type information. Solution with unknown preserves types so we can benefit from it, have nice autocomplete, type safety, etc...
Tell me please if I am wrong, and why do not use this nice solution?

Really this issue is open since 2017 and seems to be very simple, people even provided ready solutions, just implement. But still type defs for isArray remains the same: isArray(arg: any): arg is any[];
So maybe I do not understand something or this issue is hanging with 86 likes for now:)
Or maybe there are some complexities using it with unknown?

+1

I encountered this problem today with code like this:

// The error goes away if you delete "readonly":
type T = readonly string[] | { color: 'red' }

function f(t:T): void {
  if (!Array.isArray(t)) {
    // Property 'color' does not exist on type 'readonly string[]'
    console.log(t.color);
  }  
}

The above code compiles without errors with @valerii15298's solution.

Barring some unforeseen consequence, this seems like a one-line fix in lib.es5.d.ts.

Barring some unforeseen consequence

I have incredibly bad news... 😅. Every time we touch this thing something breaks. Happy to take a PR to try, though.

The suggested change leads to a backwards incompatibility and (I think) inconsistency though:

function f(v: unknown) {
  if (Array.isArray(v)) {
    // BEFORE:
    // `v` is `any[]`
    //
    // AFTER:
    // `v` is `unknown[] | readonly unknown[]`
  }
}

Currently the narrowed type is a mutable array and the suggested change would make it either mutable or immutable when the variable type is unknown or any.

But I agree that Array.isArray's return type should be unknown[] instead of any[]. And I agree with the problem shown in the original post, I just don't know a solution.

@RyanCavanaugh Would you try this PR? #48228

I modified #42316 (comment) with the following overloads, to fix this issue and #33700, without changing the current behavior of any and unknown:

    isArray<T>(arg: ArrayLike<T>): arg is readonly T[];
    isArray<T>(arg: Iterable<T>): arg is readonly T[];

typescript@4.6.3

  let a: string[] | number = 42

  if (Array.isArray(a)) {
    console.info(a)
    // let a: number & any[]
  }

  a = []

It's really wired that we got a number & any[] in the if (Array.isArray(a)) guard block.

ts(2358)

  // ERROR: The left-hand side of an 'instanceof' expression must be of type 'any', an object type or a type parameter.ts(2358)
  if (a instanceof Array) {
    // ...
  }

That's just control flow analysis; the type of a has already been narrowed to number upon the assignment of 42. Control flow can't possibly make it into that console.info(a) block unless, somehow, a were both a number and an array, and hence number & any[].

Hmm, you keep editing that comment. Let me know when it stabilizes.

@jcalz Thanks for pointing the control flow analysis to me!

After a few tests, I started understanding the a: number & any[] means:

1. Because in my code above, even the a has a static typing of number | string[], but it only has been assigned a number, which means it can only be a number
2. In the following code we tested the Array.isArray(a), which it can have to result according to the static typing and the flow control perspective:
   1. from static typing, the a has two types: string[] and number, and if we consider this, the inner block of if(Array.isArray(a)) { /* ... */ } should be string[]
   2. however, from the flow control, the a has only been assigned a number, which means it can not be an Array, so in the if(Array.isArray(a)) { /* ... */ } block, the TypeScript can not infer any array types, but it must be an array, this leads to we got an an[] type.

I'm still trying to test its behavior (you see my modification in the above issue), I feels that:

1. if we respect the static typing, then we should follow the static typing definition, get a string[]
2. if we respect the flow control, then we should use an unknown[] instead of any[], which will less confusing.

Here's a similar post: Question about Array.isArray() and unknown[]

Conclusion

My 2 cents will be:

1. We should not use any[] but an unknown[] will be more suitable
2. Or, we should use never because those two types (static & flow) have null overlap at all.

I couldn't get the above solutions to work for my use case so I made a local isArray function. Here it is incase others find it helpful:

export function isArray(
	arg: ReadonlyArray<any> | any
): arg is ReadonlyArray<any>;
export function isArray(arg: any): arg is any[] {
	return Array.isArray(arg);
}

@RyanCavanaugh please bring some attention to this issue

I think I've got a solution that extracts the relevant array type without breaking the any and unknown cases. Actually, I've got two solutions. The first one does slightly break compatibility in the unknown case, but in my opinion, it's a good break. But for those who would consider that unacceptable, I've also got one that maintains full compatibility.

In both cases, they're built upon the backs of the many giants who fell down this rabbit hole before me.

First, the breaking solution:

type IfUnknownOrAny<T, Y, N> = unknown extends T ? Y : N;

type ArrayType<T> = IfUnknownOrAny<
    T,
    T[] extends T ? T[] : any[] & T,
    Extract<T, readonly any[]>
>;

declare global {
    interface ArrayConstructor {
        isArray<T>(arg: T): arg is ArrayType<T>;
    }
}

The breaking change here is that if your starting type is unknown, then you'll end up with unknown[] instead of any[]. I think this is a good thing. If you're using unknown, then you're not looking for the unchecked semantics of any, and the only thing that Array.isArray has told you is that your value is an array of something. Since you don't know yet what that something is, unknown[] seems like the sensible representation.

But the behavior of the current official library does result in giving you an any[], even when you start with unknown. So for those who have dependencies on that behavior that they can't easily change, this version preserves it:

type IfUnknownOrAny<T, Y, N> = unknown extends T ? Y : N;
type IfAny<T, Y, N> = (T extends never ? 1 : 0) extends 0 ? N : Y;

type ArrayType<T> = IfUnknownOrAny<
    T,
    IfAny<T, T[] extends T ? T[] : T[] & T, any[] & T>,
    Extract<T, readonly any[]>
>;

declare global {
    interface ArrayConstructor {
        isArray<T>(arg: T): arg is ArrayType<T>;
    }
}

Static analysis confirms the types I would expect for everything I've thus far tested.

First, we have some tests showing the current behavior, which doesn't result in selecting the preferred type in some cases (primarily when the input type could be a read-only array).

Next, we have the first version above, which opts for the more correct unknown[] type when the starting type is unknown. It's also slightly simpler.

Finally, we have the compatible version that will still produce any[] when the input type is unknown.

I've found an oversight in my ArrayType<T> above (either version of it). If T is object, then the resolved type is never, which is obviously not right.

const object: object = {};
if (Array.isArray(object))
    typeOf(object).is<never>("🟢 true");  // 😞

So I tried a simplified version of @graphemecluster's implementation:

type ArrayType<T> = Extract<
    true extends false & T ?
        any[] :
    T extends readonly any[] ?
        T :
    unknown[],
    T
>;

This one works correctly for all my previously tested cases, plus ones involving object.

Note that, like my first version, it converts unknown to unknown[], which is incompatible with the current production Array.isArray, which would return any in this case. I still think this is the better behavior, but it's a breaking change.

I also made a more compact, less explicit version of these tests.

@P-Daddy I would like to see unknown being converted to unknown[] too – but unfortunately in my trial there are too many compatibility errors related to unknown[] – see #50454 (comment). Please also see my test case files and see if I'm missing something, and do try out a workable solution yourself with a PR. Remember to deal with ArrayLike and Iterable too. My solution seems to be too complicated that is likely unacceptable by the Team.

@RyanCavanaugh @sandersn Suppose my solution is still not feasible and convincing enough (at least from TypeScript 4.8), has the Team ever considered using an intrinsic type? I guess it must be one of the most probable solutions for this long-standing issue.

I'll bring it to the design meeting next week. This is incredibly subtle, unfortunately.