.every() .find() .filter() methods fail with "This expression is not callable." error on union of array types

[ialexryan]

Bug Report

🔎 Search Terms

• This expression is not callable
• none of those signatures are compatible with each other

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about union types. I also reviewed previous related issues.

⏯ Playground Link

• .every() does not work
• .filter() does not work
• .find() does not work
• .reduce() also doesn't work, but there is already an issue for that one. (Perhaps we should merge it into this?)

💻 Code

interface Fizz {
    id: number;
    fizz: string;
}

interface Buzz {
    id: number;
    buzz: string;
}

([] as Fizz[] | Buzz[]).filter(item => item.id < 5); 

🙁 Actual behavior

Compilation fails with the following error:

This expression is not callable.
  Each member of the union type '{ <S extends Fizz>(predicate: (value: Fizz, index: number, array: Fizz[]) => value is S, thisArg?: any): S[]; (predicate: (value: Fizz, index: number, array: Fizz[]) => unknown, thisArg?: any): Fizz[]; } | { ...; }' has signatures, but none of those signatures are compatible with each other.

🙂 Expected behavior

Compilation succeeds, as it does for map and several other array functions.

🔖 Useful links

• Original issue
• PR that closed original issue

[DanielRosenwasser]

Duplicate of #36390

https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+array+%22This+expression+is+not+callable%22

[ialexryan]

Hi @DanielRosenwasser, please check out my comment on that issue (also linked in the writeup above). This issue is a followup to #36390, not a duplicate. That issue was closed when #31023 fixed the majority of array functions to work with unions of array types. This issue (and #44063) track the handful of array functions which still don't work post-#31023.

If you'd rather reopen #36390 and rewrite the title and description I suppose we could dedupe this in, but given that there was so much activity there dating back years, and that most of the usecases motivating that issue have in fact been solved for, it seemed much clearer to me to track the remaining bits of cleanup separately here.

[RyanCavanaugh]

@weswigham what's the current state of what we might be able to do here?

[weswigham]

Well, we'd need to come up with sensible rules for merging overload lists. Conceptually, we could (attempt to) make a list of 4 overloads by combining each of the input signatures, except there's no inherent ordering to those 4 signatures, unlike a normal overload set, so it's unclear how we'd choose which signature to resolve against, ultimately.

[jfamousket]

As a workaround for anyone searching lodash's filter function works as expected

[ITenthusiasm]

@weswigham Is there anything in particular that makes methods like filter difficult to work with compared to map? I haven't looked at the type definition in TS. But from a JS standpoint, the two signatures are the same; so it's a bit surprising that the methods involving predicates are more complex.

[jcalz]

Maybe something could be done specifically for arrays instead of worrying about merging arbitrary signatures? Like, widen A[] | B[] to readonly (A | B)[] for these failing method calls? 🤷‍♂️

[dderjoel]

Can we add concat to that list above, too?
I have a typescript-playground showing this here.

const m2 = [] as Array<number> | Array<string>;
m2.map(it=>it); // why does that work ?
m2.reduce((it) => it); // error
m2.concat(m2); // error

[vassudanagunta]

• .reduce() also doesn't work, but there is already an issue for that one. (Perhaps we should merge it into this?)

I think it should be merged; if not then its description "Array.reduce doesn't work" needs to be improved. See 44063.