[3.9] Complex types truncated in declaration files

[ostrowr]

TypeScript Version: 3.9.0+ (works in 3.8.x, broken in 3.9.x, 4.0.x)

Search Terms:
truncated, "...", declaration

Code

I'm still working on getting a scoped repro here, and will update this ticket when I have one. But – in TS 3.8 (and earlier), I have a complex type that produces the following code in a .d.ts file:

<-snip->
removed: (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[]) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & string) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & number) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & false) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & true) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & {
                [property: string]: import("ts-json-validator/dist/json-schema").JsonValue;
            }) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[] & readonly import("ts-json-validator/dist/json-schema").JsonValue[]);
<-snip->

In 3.9+, this gets truncated as though we're in an editor environment:

removed: (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                [k: string]: unknown;
            }[]) | (import("ts-json-validator/dist/json-schema").JsonValue[] & {
                ...;
            }[] & string) | ... 4 more ... | (import("ts-json-validator/dist/json-schema").JsonValue[] & ... 1 more ... & readonly import("ts-json-validator/dist/json-schema").JsonValue[]);

Expected behavior:
Types aren't truncated in .d.ts files

Actual behavior:
Types are truncated, producing syntactically invalid .d.ts files

Related Issues:

• Not directly related, but Setting noErrorTruncation to false truncates inferred type of variables/functions; which are not errors #26238 has some investigation about information placeholders

[RyanCavanaugh]

How big was your .d.ts output in 3.8? We introduced a cap on type display to avoid printing impractically-large types (> 1 million chars)

[ostrowr]

Almost 2.8 million chars, generated from about 50 lines of code in the corresponding .ts file...

Many of these characters are of the form import("ts-json-validator/dist/json-schema")., so assigning that to some intermediate value would probably save a lot of characters. I don't know if .d.ts supports that.

That's what I get for ridiculous recursive types. The file at issue defines three schemas from https://github.com/ostrowr/ts-json-validator; I'll try splitting them into three files. But 3.9 makes that library pretty useless if there's a cap on type size. Is this value configurable?

[weswigham]

so assigning that to some intermediate value would probably save a lot of characters

We don't do it in the emitter ourselves, however if you write
import * as js from "ts-json-validator/dist/json-schema" at the top of the input file (or specific imports for each of the referenced types!), we'll use the js reference that now exists over serializing the full thing, which can be a workaround for now, if you think that's enough to shave enough characters to get back under the limit.

[ostrowr]

Thanks! That workaround fixes the issue in my codebase (with some ts-expect-error and eslint-ignores around unused variables) even though the .d.ts is still more than a million characters. Naturally, this isn't a super satisfying fix.

Can you point me to the PR or discussion around introducing this limit? I don't understand why it was introduced, but I'm sure there are plenty of reasons. In any case, compilation should probably fail with a nice error message when the limit is reached, not emit invalid code.

Philosophically, this is similar to my comment here: #35533 (comment) – it's OK for typescript not to be able to do something, but when it can't do something (and is able to detect that it's in that situation) it should yell at the user whenever possible!

[weswigham]

#37461 - you are correct in that we should consider issuing an error when this occurs, rather than relying on people noticing that the output itself contains a truncation.

[ostrowr]

Ah, makes sense why your workaround fixed it even though the doc is over a million characters. Looks like the real maxLength is 2 * 1 million.

I'll consider diving in to try to issue an error in this situation, but can't promise I'll get to it soon! It looks a little less trivial than I expected since it seems that this code implements shared functionality for when truncation really is needed.

(Also makes sense why --noErrorTruncation didn't fix the issue for me.)

[weswigham]

Looks like the real maxLength is 2 * 1 million.

Node truncation starts at 1 million estimated length (and thus stop building synthetic AST nodes), the final string is just also hardcapped at 2 million, in case the estimate and the real final size are very different.