Exploring the Concept
I realized that linking TypeSpec with stable Go code generators would bring significant added value to my API projects. Now it was time to create a rough sketch.
Available Emitters
TypeSpec already provides several emitters—for OpenAPI, Protobuf, and JSON Schema, for example. OpenAPI was quickly ruled out for my purpose: while there are several projects that generate Go code from it, I’ve never been truly convinced by any of them. Protobuf would require its own decorators in TypeSpec to map all details accurately—something I wanted to avoid. And JSON Schema cannot fully transport all type information.
The Need for a Custom Emitter
That made it clear: I needed my own emitter. My first attempts used the emitter framework to generate Go code directly. It worked reasonably well, but in the end, it was essentially just template-based rendering. What was missing was a real “understanding of Go.” However, it was important to me that the generator truly comprehends its target environment.
Bridging Two Worlds
The process will therefore operate in two worlds: TypeSpec and Go—each with its own appropriate, specific tooling. A clean intermediate format will transport all necessary information while remaining as simple and manageable as possible. Based on this, a Go tool will then use AST techniques to produce proper, idiomatic code.
This concept works for all desired components: server stubs, client libraries, a mock server (which could build on the stubs), and a CLI to interact with APIs interactively—similar to JetBrains’ HTTP client.
Focus on Go First
The focus is entirely on Go for now, though I’ll certainly explore other languages later. TypeScript would be the next interesting candidate. At this stage, however, nothing more than the concept and a rough architectural outline has been developed.
A Clean Approach
Ultimately, the approach felt clean: no unnecessary dependencies, clear separations, and the confidence that the tooling will deliver exactly the results I want.