Typescript "inferred type ... exceeds maximum" error with Exact

[jacobfederer]

I'm trying to distribute the generated proto classes/constants inside a npm library. Therefore I need to compile the Typescript code into JS using tsc. However this fails due to an tsc error:

proto/abc.ts:3398:14 - error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

3398 export const SomeMessage = {
                  ~~~~~~~~~~~~~~~~~~~~~

proto/abc.ts:3531:14 - error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

3531 export const AnotherConstMessage = {
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

proto/abc.ts:3620:14 - error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

3620 export const AnotherConstMessage = {
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My first idea was to shorten the proto files and to move messages into more files, but this doesn't seem to help.

How can I attach a "type annotation" ? Is there a way to distribute Typescript files without compiling them?

[stephenh]

Wow, how many fields do you have in you messages?

I suppose we could detect "this message has more than N fields" and then output an explicit type annotation for it.

...I almost wonder if we shouldn't just use a class, b/c even though "just data / interfaces" is one of ts-proto's design goals, admittedly at the end of the day, with TS's structural typing, as long as you don't have private fields, I'm ~pretty sure we could output class here (to avoid repeating the type + impl, which is what a class basically does), and have code that works with the SomeMessage be none-the-wiser about whether it was defined as a class or const...

[jacobfederer]

Not a lot, in one message that fails to compile I only have 5 fields. But I suspect that this might be an issue due to the use of recursion.

Other people solved the issue by altering their recursive function/combined type use: Stackoverflow, microsoft/TypeScript#43817

Regarding the class usage: When I first go started with the library the separation of data/implementation confused me a bit. It might be easier to use if both are together in one class.

If you want, I can give you access to our proto library.

[jacobfederer]

I tried commenting the fromPartial<I extends Exact<DeepPartial<XYZ>, I>> method out on one of the constants and it might have actually worked since Exact seems to be the problematic/recursive element in the generated files.

[stephenh]

@jacobfederer we just added an option to disable the Exact type, see #454; can you try enabling that option and see if that fixes it for you?

If it does, it'd be really great to have a minimal *.proto that reproduces the compile error, to see if it's something that we could fix in the Exact types.

Thanks!

[jacobfederer]

@stephenh I tested it yesterday, it works well. Tsc compiled it a lot faster.

I'll provide a minimal reproduction when I'm back from my holidays (start of the next week).

[tidhar-ziv]

Generating code from Temporal.io API (https://github.com/temporalio/api/tree/master/temporal/api) will produce JS code failing with the same error, if using a ts-proto version later than 1.91.0

[mvniekerk]

Confirming last working version was 1.91.0

[stephenh]

Late reply, but right @mvniekerk the Exact type was introduced in v1.91.0 but can be disabled with --ts_proto_opt=useExactTypes=false if it causes issues in your output.