typespec VS guardrail

It does not exist, but it will be worked on fairly soon. You can track progress on GitHub [1]. It will be as you suggest - a one time conversion, after which you can iterate. We have this workflow for inside Azure, but the converter is Azure-specific (e.g. converts to TypeSpec that uses our extensive Azure-specific component library). It will take a bit to generalize.

[1]: https://github.com/microsoft/typespec/issues/3038

Afaik there's nothing that's widely used and of which I'd say I prefer it. But I'm having hopes for https://github.com/microsoft/typespec (former cadl). The reason being that yaml/JSON specs get huge very quickly, OpenAPI has to fight with restrictions of yaml/JSON ($refs, splitting up into files, oneOf, etc.) and tooling is ok but not great.

You've touched on some use cases I've thought about and led me to ask the question.

I also recently saw Microsoft take a higher level approach with CADL/Typespec: https://microsoft.github.io/typespec/ which could be cool if it reaches wide adoption.

This one just crossed my feed today: Cadl, "... a language for describing cloud service APIs and generating other API description languages, client and service code, documentation, and other assets."

What's the use case? I was thinking about this exact issue because my product ships several CLI tools, but I wasn't convinced it would be worth the effort.

An OpenAPI specification describes an HTTP interface, and I see it as useful because it makes it easier to write code in language-of-choice to generate HTTP requests (by generating client libraries from the OpenAPI spec).

For a CLI, the interface is the command-line. Usually people type these commands, or they end up in bash scripts, or sometimes they get called from programming language of choice by shelling out to the CLI. So I could see a use case for a CLI spec, which would make it easier to generate client libraries (which would shell out to the CLI)... but it seems a little niche.

Or maybe, as input to a documentation tool (like Swagger docs). I would imagine if you're using a CLI library like Python's Click, most of that data is already there. Click Parameters documentation: https://click.palletsprojects.com/en/8.1.x/parameters/

Or maybe, you could start from the spec and then generate code which enforces it. So any changes pass through the spec, which would make it easy to write code (server and client-side) / documentation / changelogs. Some projects like this: Guardrail (Scala) https://github.com/guardrail-dev/guardrail , and Connexion (Python) https://github.com/spec-first/connexion .

But without this ecosystem of tooling, documenting your CLI in a specification didn't really seem worth the effort. Of course, that's a bootstrapping problem.

You may have some luck with Guardrail https://github.com/guardrail-dev/guardrail/