Any better workarounds for TS7056?

I’m responsible for a project with pretty complex schemas. We’re running into a lot of TS compile errors like this:

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

The best workaround I’ve found is to annotate schema declarations with zod types ahead of time (rather than using z.infer):

export type ZBlockEntity = z.ZodUnion<
  [
    typeof paragraphPropsOrElement,
    typeof layoutPropsOrElement,
    ...
    typeof escapeElement
  ]
>
export const blockEntity: ZBlockEntity = z.union([
  paragraphPropsOrElement,
  layoutPropsOrElement,
  ...
  escapeElement,
])

TypeScript will declare the array of typeof name referentially with this explicit annotation, otherwise it repeats a literal of each schema in the union.

The example I gave was simple, but some schemas that are hitting TS7056 are very tricky to mint and maintain explicit type annotations for, and even if it’s achievable it will greatly increase technical inertia for the features that hit that wall.

I’d like to find a way to compile schemas in a way that TypeScript can declare and reuse named types instead of it repeating the same literals so many times it breaks.

Is there a workable solution here, or have we hit a wall?

[thure]

I’m not sure it would… regardless of the value of declaration, the project needs to build type declarations since it’s an intermediary package.

Maybe a top-level app could avoid emitting declarations, but this project can’t.

[thure]

The project is open source, yes. We’re getting TS7056 in these examples:

• Card content item entity
• Card props or element

There are several others. You can see them by running pnpm build from packages/react (I think there was also one in packages/schemas) at this commit in the project: https://github.com/OfficeDev/fluent-blocks/tree/536f8dceccfc8142438f02d8aa6530977c76879b (it’s the moment I discovered the issue before starting to try to fix it).

TS7056 happens mostly when you’re putting a lot of schemas and other types into the same namespace

Letting TS7056 be the test for whether a name shares a file with another feels wrong-headed to me. You can see in the examples we’re not exporting very much from the package, it’s just very deeply composed.

That composition is why I’m asking, is there a way to cause tsc to refer to types rather than repeat literals? This seems to be the real issue.

As it is, maybe rather than the source of truth coming from zod, it should start with TypeScript, and we should use ts-to-zod to produce & refine schemas. I am experimenting with that now, since it appears to be the only way to ensure tsc creates and uses an identifier for the types that need them.