Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types.<p>On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we&#x27;re spending all this effort turning a preprocessor&#x27;s type system into a turing-complete metalanguage. Pretty soon we&#x27;ll be able to compile TypeScript entirely using types.

This would be even nicer if TypeScript added type inference for tagged template literals, like in this issue [1]. Then you could write:<p><pre><code> const schema = proto` syntax = &quot;proto3&quot;; message Person { ... } `; type Person = typeof schema[&#x27;Person&#x27;]; </code></pre> And you could get built-in schema validation with a sophisticated enough type definition for `proto`, nice syntax highlighting in many tools with a nested grammar.<p>We would love to see this feature in TypeScript to be able to have type-safe template in lit-html without an external tool.<p>The issue hasn&#x27;t seen much activity lately, but it would be good to highlight this library as another use case.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;33304">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;33304</a>

It’s pretty rad how flexible template literal types are, but I can’t imagine wanting this kind of shenanigans hanging out in a production app slowing down compile times. I prefer to define types in TypeScript and generate proto from that, since the TypeScript type system is so much more powerful than the Protobuf system. Types are much more composable in TS.

This is kinda why I hate advanced type systems, they slowly become their own language.<p>&quot;No compile&#x2F;no codegen&quot; sounds nice until you get slow compile times because a type system is slow VM, the error messages are so confusing it&#x27;s hard to tell what&#x27;s going on, and there&#x27;s no debugging tools.

I love this, and I bet the compile errors it produces on malformed protobuf are <i>wild.</i>

What&#x27;s kind of amazing is that Typescript&#x27;s matching of strings through the type system converges on a first-class PEG in a few places (see string.ts). The rest of the library is really damn succinct for how much lifting it&#x27;s doing.<p>My hat&#x27;s off to the author - I attempted something like this for a toy regex engine and got nowhere fast. This is a much better illustration of what I thought _should_ be possible, but I couldn&#x27;t quite wrap my head around the use of the ternary operator to resolve types.

Cool, but I assume not great for performance?<p>Probably better to just stick with codegen

This is both hilarious and awesome. I think the Typescript devs are just showing off at this point. :D

This is super cool — love the zero-codegen approach. I’ve had to deal with codegen hell in monorepos where a tiny .proto change breaks half the pipeline. Curious how this handles more complex types like nested messages or oneof fields?<p>Also, been building something in a different space (LeetCode prep tool), but the idea of removing build steps for dev speed really resonates. Would love to see how this could plug into a lightweight frontend setup.

This requires the whole `.proto` declaration inline in source a string constant. I&#x27;m not holding my breath on &quot;Import non-js content&quot;[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it&#x27;s not clear when this would be a benefit over straight-forward code gen. Cool POC hack though.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;42219">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;42219</a>

This makes me wonder if this the way to do schema generation in Typescript. I’m working on Typeconf, and we have a separate step for translating Typespec schema to Typescript, it’ll be cool if we could just load typespec directly.

Looks like TypeScript envies Swift&#x27;s compile times.

Very cool work!<p>Also, I hope you expected me to read that output in the same cadence as the Hooli focus groups, because that&#x27;s exactly what I did.

Cool. Once the linked TS issue is resolved it will be able to resolve from files too which is great

It&#x27;s always impressive how far people can take TypeScript and even build parsers with it. But this is limited to inlined string literals and cannot read files (a TS limitation).<p>I wonder if the author has a use case in mind for this that I don&#x27;t see. Like if you are only using TS, what&#x27;s the point of protobuf? If you are exchanging data with programs written in other languages why avoid the protobuf tooling that you need anyway?<p>Maybe this is just a fun toy project to write a parser in TS?

I wish there was other way around. infer binary encoding from native types