stephenh
Typescript compiler fails to compile ts_proto generated files to js
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?
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...
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.
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<DeepPartial> seems to be the problematic/recursive element in the generated files.
@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!
@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).
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
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.