Excessive stack depth comparing types 'FlatArray<Arr, ?>' and 'FlatArray<Arr, ?>'.

[RomanKornev]

TS and JS Grammar Extension version: ms-vscode.vscode-typescript-next v4.3.20210312
Trying to use configureStore with middlewares, getting the following error:

A couple days ago it was fine.
Also getting a lot of similar Excessive stack depth errors for other parts of the code.
Code

import { configureStore, getDefaultMiddleware } from '@reduxjs/toolkit'

configureStore({
    reducer: {
    },
    middleware: [
        ...getDefaultMiddleware(),
    ],
})

[kudryavtsev-dmitry]

I changed TS version from vscode version 4.3.0 to workspace 4.2.3, and this fixed my problem.

[utkarshk384]

@kudryavtsev-dmitry Thanks bud, you saved my day :). Been getting this error all over my react project for almost a week! :(

[ghost]

Typescript nightly for vscode throw this error v4.3.20210314

[andrewbranch]

I have a simple fix, but I don’t think it gets to the core of the issue. Via bisecting, I found that the problem was introduced in #30639 (cc @weswigham). Here’s a minimal repro:

// @lib: es2019
interface MiddlewareArray<T> extends Array<T> {}
declare function configureStore(options: { middleware: MiddlewareArray<any> }): void;

declare const defaultMiddleware: MiddlewareArray<any>;
configureStore({
  middleware: [...defaultMiddleware], // Should not error
});

The problem starts when we need to know if defaultMiddleware is an array-like type. We can’t take the preferred shortcut of finding that it’s a simple reference to Array or ReadonlyArray since it’s a MiddlewareArray, so we start checking assignability to readonly any[], and then we overflow while comparing each array’s .flat() call signatures.

I haven’t yet dug into why #30639 causes that comparison to overflow, but it seemed like we should really never have to do that work at all—if a type has Array or ReadonlyArray as one of its base types, I think we already know that it’s array-like. I have that fix ready to go if we want it, but we should probably figure out if we need another fix for conditional type assignability.

[andrewbranch]

Confirmed my isArrayLike change fixes the repro in #43258 too.

[jonlepage]

confirm back to 4.2.3 work ! .
4.3.0> trow this error.
Excessive stack depth comparing types 'FlatArray<Arr, ?>' and 'FlatArray<Arr, ?>'.ts(2321)

[danielo515]

In my case it is happening using recharts recharts@1.8.1 and typescript@4.2.3

[junhoyeo]

I was having the same issue with typescript@4.2.3, and then I noticed that I wasn't wrapping the mapped result into a Fragment. Now I have no errors 😄

+ <>
  {data.feeds.map((item, index) => {
    return <div key={someKey}>{JSON.stringify(item)}</div>
  })}
+ </>

[danielo515]

I was having the same issue with typescript@4.2.3, and then I noticed that I wasn't wrapping the mapped result into a Fragment. Now I have no errors 😄

+ <>
  {data.feeds.map((item, index) => {
    return <div key={someKey}>{JSON.stringify(item)}</div>
  })}
+ </>

But this is a perfectly valid react pattern, you should not need that as soon as you have a parent component

[Jack-Works]

Having this problem in 4.3.0-dev.20210327 in many JSX code

[earthlyreason]

I ran into this when trying the 4.3.0-dev.20210329 nightly with code that destructures RegExp matches. Here is the minimal repro I could find (Playground link):

const repro_43249 = (value) => {
  if (typeof value !== "string") {
    throw new Error("No");
  }

  const match = value.match(/anything/) || [];

  const [extracted] = match;
  //     ~~~~~~~~~^ Excessive stack depth comparing types 'FlatArray<Arr, ?>' and 'FlatArray<Arr, ?>'
};

You can reproduce this with the following tsconfig.json:

{
  "compilerOptions": {
    "lib": ["ES2019"]
  }
}

Curiously,

• it only occurs with lib ES2019 and above
• it goes away if you get rid of the throw
• it goes away if you change the typeof check to anything else

I notice that npx tsc test would not produce it, but npx tsc -p tsconfig.json would.

[Argiziont]

<></>

This attributes works perfectly but it's unnecessary as pointed out before

[zackdotcomputer]

Trying to understand the current state of this bug. It's still occurring as of the 3/30 nightly - I just ran into with a string interpolation in JSX and was able to fix with the "wrap it in a React.fragment" as suggested.

Is there currently a PR open for a fix or are we at least vaguely sure of why this is happening? (I know @andrewbranch mentioned having a possible solution above.)

[andrewbranch]

Found a repro that is not fixed by #43435:

function f<Arr, D extends number>(
  x: FlatArray<Arr, any>,
  y: FlatArray<Arr, D>
) {
  x = y;
  y = x;
}

[DetachHead]

so did i, though it may be the same thing #43493

[ahejlsberg]

With #43527 we should have this issue taken care of for good.