Vilsol
Vilsol
Slight update: Looks like defining the convertors below seem to fix it, however that adds a lot of bulk if you have deeply nested structs that are used all over...
Going through the codebase, it seems like the easiest solution would be to add this: ```go if ctx.IdentityMapping != nil { namedType := target.NamedType if target.Pointer { namedType = target.PointerInner.NamedType...
In those cases maybe it would be possible to detect if a definition of the type conversion exists, and then merge their contexts?
I'm not sure I understand why someone would define a double definition for the same conversion?
Indeed this would add a lot of potential magic. However my issue is that if you are converting from a flat struct to deeply N nested anonymous structure that is...
Indeed that example does not work, as I was only working with the presumption of anonymous nested structs. Maybe an option would be to maintain a parent inheritance tree throughout...
@NimrodAvni Try using `ES2018` and enabling `strictNullChecks` You can also try disabling exact types: `--ts_proto_opt=useExactTypes=false`
Actually, this seems like a bigger issue than I first thought. It looks like if you import types for NodeJS > 14, the `Exact` completely breaks. Our 2 options for...
I think we should implement a dummy and make it ErrorLog that a packet with "this" hex ID isn't registered
@AgentTroll Yespls