Setting Up the Project Foundations
Even though we now generate OpenAPI specs directly via TypeSpec, a small, custom emitter is still used. This controls
specific details to prepare the spec optimally for ogen. Currently, this primarily concerns strict validation of
payloads to prevent additional, undefined fields from being transmitted.
This gives the user complete freedom in choosing the runtime—whether Node, Deno, or Bun. Although this could be made configurable via the CLI, maintaining a clean separation without hidden background processes is very important to me.
Project Structure and Tooling
Instead of relying on classic Makefiles or scripts in package.json, all relevant tasks are provided via a Taskfile
in the repository. To leverage greater scripting functionality, shell scripts are used, which are natively supported by
Task. Particularly in projects like this, where different technologies meet, Taskfiles are excellent: they cleanly
manage all tasks, are platform-independent, and make it possible to list all available commands directly in the console.
The actual CLI resides under /cmd/spec-cli/. The associated logic is located within /internal/, since we currently
don’t plan to share functionality directly as a public Go package. The TypeScript emitter is managed in the /emitter/
directory.
The repository has already been created: Spec CLI Repo. It’s still
private, as it contains no usable content yet beyond the basic structure, go.mod, a package.json in the emitter
folder, and the Taskfile.yml. But the foundation is laid. This is precisely the point where I can now begin
implementing the emitter.
The decision to use a specialized emitter to pre-filter the OpenAPI spec is strategically wise, giving
ogenexactly the “food” it needs for stable Go code. The choice of Taskfiles over Makefiles underscores the project’s modern, cross-platform approach and significantly simplifies contributions from other developers.