Typescript: "The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed."

Question

I'm getting the error

"The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed."

This was working fine a few hours ago... nothing that I've changed (update npm and node) makes any sense as to why this would happen.

I absolutely can not give an explicit type annotation.

---

What I've tried:

This is my third complete rewrite of the tool I'm trying to make because Typescript keeps lagging out about it.

After three full rewrites, hundreds of hours, and extreme effort everything had been working fine for one whole day before this error started popping up.

I've tried updating everything (typescript, node, npm... nothing else to update)

I've tried updating tsconfig:

"compilerOptions": {
        "disableSizeLimit": true,

---

I have no idea what to do. The only alternative I can imagine is throwing Typescript in the trash and doing type checking at compile time... which would be fine for this project I guess.

---

On attempt 2 of this project, I asked about better caching

Sladen

Like most performance issues, this is not something that has a magical solution. The only way to "fix" this is going to be examining that type and making it simpler somehow. We may be able to help you with that, but you've haven't posted those types. So I don't you'll get much help from this question as is. – Solent

The type is already as simple as it could be. I had a more perfect version, but cut a ton of corners to get it simplified. In my "demo" it's extremely fast with no hiccups. But once put into an npm package, then run with the exact same demo code, it dies. It was also working fine recently. I honestly don't know how much more I could do here. – Sladen

please share reproducable example – Rileyrilievo

@captain-yossarian, I've been trying to make a minimal example. But the thing is, this is one of those errors that all of my testing before hand didn't create. The moment I tried using the tool in production (with larger objects), that's when the issue started happening. A MVP for something like this is not possible, this is a production environment issue. – Sladen

Answer 1

"declaration": false,

set declaration to false in tsconfig.json works for me

also found related topic on github https://github.com/microsoft/TypeScript/issues/43817

this is caused by recursion, which is also my case

update: apparently this is the real solution:

type Builder<T> = {
    withComment: (comment: string) => Builder<T & { comment: string }>,
    withSpecialComment: () => Builder<T & { comment: string }>,
    withTrackingNumber: (tracking: number) => Builder<T & { tracking: number }>,
    build: () => T
};

const Builder: <T extends {}>(model: T) => Builder<T> = <T extends {}>(model: T) => ({
    withComment: (comment: string) => Builder({ ...model, comment }),
    withSpecialComment: () => Builder(model).withComment('Special comment'),
    withTrackingNumber: (tracking: number) => Builder({ ...model, tracking }),
    build: () => model });

const a = Builder({});

https://github.com/microsoft/TypeScript/issues/43817#issuecomment-827746462

with this you don't need to set declaration to false

Babylonia

Answer 2

Okay, I've managed to drag this project on just a little bit further. Here is the primary change I made:

Convert interface unions/intersections to class unions/intersections

I don't know why this works, but if you have some complex union/intersection like so:

interface A { 
  a: true,
  // code omitted...
}

interface B { 
  b: true,
  // code omitted...
}

// code omitted...

type ComplexIntersection = A & B & C & D & E & F & G;

You can switch all the interfaces to abstract classes like so:

abstract class A { 
  public abstract a: true;
  // code omitted...
}

abstract class B { 
  public abstract b: true;
  // code omitted...
}

And the Typescript language server will be happier about it. I have no idea why this works, but here's what the type looks like

before:

and after:

---

Other things I tried that didn't work:

1. Removing every complex type I could find
2. Removing every generic argument I could

Sladen

Answer 3

I encountered a similar issue with one of my type libraries today. The problem stemmed from not exporting one of the types in a complex type chain. As a result, TypeScript tried to infer all the types behind that unexported type instead of using it directly because it couldn't access the type in my calling package. Once I exported the type from the library, everything worked as expected.

Here's an example to illustrate:

Library package

import { MoreComplexType } from './type' // <- also exported from lib
/*not exported*/ type SomeComplexType<X> = {
    doStuff<P extends string>(): MoreComplexType<P>
}
export function createSomething<M>(builder: () => M): SomeComplexType<M> {};

Application package

import {createSomething} from 'lib'

interface Model { ... }

const something = createSomething(() => model<Model>()) // <- breaks
const somethingExplicit = createSomething<Model>(() => model<Model>()) // <- breaks even with an explicit annotation

In this case, TypeScript tried to infer SomeComplexType because it wasn't accessible in the app package. After exporting SomeComplexType from the library, it worked just fine and TypeScript used SomeComplexType correctly in the app package.

Maybe it help someone

Bybee

Answer 4

I had this problem on typescript vue3 code. It showed up suddenly, without any changes to the file.

It isn't the actual error, at least in my code. In a imported interface in an associated service file, there was a composite interface that referenced another one LATER in that file, rather than before.

It's an easy mistake to make, and vsCode didn't catch the error right when I did it. The code even compiles and runs just fine. Once I fixed the error in the referenced file, the bogus message went away.

Puton