TS 5.1.1-rc: RangeError: Maximum call stack size exceeded

[belgattitude]

Bug Report

Tried an upgrade to 5.1.1-rc from 5.0.4 and got a RangeError: Maximum call stack size exceeded for one of the app of the monorepo (nextjs, mui, i18next,...). Others apps and packages works.

You'll find a reproduction here: belgattitude/nextjs-monorepo-example#3826 with explanation.

git clone https://github.com/belgattitude/nextjs-monorepo-example.git --branch typescript-5.1.1-rc 
yarn install
cd apps/nextjs-app
yarn typecheck

Note that this repo uses yarn 4.0.0-rc.44 with node_modules linker.The cause might be linked to that as well. But in general this example repo used to work across ts updates quite well.

The error is visible on the CI https://github.com/belgattitude/nextjs-monorepo-example/actions/runs/5049578076/jobs/9059197251?pr=3826 and reproduced locally on linux / node 18.16

Just wanted to let you know, didn't had time to investigate.

Huge thx for ts team, I really appreciate what you're doing ❤️

🔎 Search Terms

RangeError: Maximum call stack size exceeded
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63011:28)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)
    at inferFromTypes (/home/sebastien/github/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63018:9)

🕗 Version & Regression Information

• This is a crash
• This changed between versions 5.0.4 and 5.1.1-rc

⏯ Playground Link

belgattitude/nextjs-monorepo-example#3826 with explanation.

git clone https://github.com/belgattitude/nextjs-monorepo-example.git --branch typescript-5.1.1-rc 
yarn install
cd apps/nextjs-app
yarn typecheck

[jakebailey]

This bisects to #53365, but reverting it doesn't actually fix the problem and it doesn't really make sense anyway. Really strange.

[jakebailey]

Ah, I see what's wrong here.

[jakebailey]

Apparently, no, what I thought was wrong was not wrong. I can only think that there's some form of corruption happening here. Except that now, I can't get this to break on main. Doing a bisect then says that we somehow fixed it on main in #54125, which is totally ridiculous.

[belgattitude]

Thank you for looking @jakebailey ... let me know if I can be of any "modest" help.

[capaj]

same here on 5.1.3 and even 5.0.4. Running with the fix from @jakebailey fixes the issue.

[belgattitude]

@jakebailey if it helps I've upgraded to ts 5.1.3 and still have the same issue
belgattitude/nextjs-monorepo-example#3888

cd /tmp
git clone https://github.com/belgattitude/nextjs-monorepo-example.git --branch typescript-5.1.3 
yarn install
cd apps/nextjs-app
yarn typecheck

The output I have / Linux - node 18

/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:114891
      throw e;
      ^

RangeError: Maximum call stack size exceeded
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63155:28)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)
    at inferFromTypes (/tmp/a/nextjs-monorepo-example/node_modules/typescript/lib/tsc.js:63162:9)

Node.js v18.16.0

There's different apps in this monorepo, so I've checked on package on which nextjs-app depends (via tsconfig path aliases)

cd packages/ui-lib
yarn typecheck

Outputs:

src/base/card/BasicCard.stories.tsx:19:8 - error TS2786: 'BasicCard' cannot be used as a JSX component.
  Its return type 'ReactNode' is not a valid JSX element.

19       <BasicCard
          ~~~~~~~~~

src/base/card/BasicCard.tsx:16:6 - error TS2786: 'S.Ctn' cannot be used as a JSX component.
  Its return type 'ReactNode' is not a valid JSX element.
    Type 'undefined' is not assignable to type 'Element | null'.

So it's possible there's a relation.

Gonna check: https://devblogs.microsoft.com/typescript/announcing-typescript-5-1/#decoupled-type-checking-between-jsx-elements-and-jsx-tag-types

And let you know

[chriskuech]

This is also an issue with nestjs, which uses parameter decorators extensively.

[jakebailey]

This was really weird, but I figured it out. The code added in #53246 directly checks the object flags of the type. When this code executes, CouldContainTypeVariables is not computed, so it proceeds to check couldContainTypeVariables for the type arguments. But, this may be recursive; the current type may actually have its objectFlags updated in the process of calling couldContainTypeVariables. If that calculation actually said "false", then this new code wrote over the old value with a new one, causing this problem.

I'm looking into a proper fix now.

[chriskuech]

I noticed in the release notes that decorators require disabling the previous compiler flags. Should the compiler at least warn that those config settings are enabled if its related to this issue?

[jakebailey]

This issue is not at all reserved to decorators; I have multiple test cases which exhibit this bug which do not involve decorators. This is just a bug that will be fixed and very likely backported to the next patch release of 5.1.

[Toinouze]

Any temporary workaround for this issue ?

[jakebailey]

You could use the build on my PR: #54507 (comment)

Or, just downgrade back to 5.0... 5.1's only been out for a couple of days.