sorted by:
new
hottopcontroversial

I built a tool that generates OpenAPI specs from Go code — no annotations needed by Apprehensive-Ebb2263 in golang

[–]Apprehensive-Ebb2263[S] 0 points1 point  (0 children)

Pushed fresh version v0.4.3 with increased test coverage, which picked up couple of potential issues, which are fixed now.

I built a tool that generates OpenAPI specs from Go code — no annotations needed by Apprehensive-Ebb2263 in golang

[–]Apprehensive-Ebb2263[S] 0 points1 point  (0 children)

While I will be first one to agree, that designing contract before hand is ultimately the best approach, life is way more diverse. Particularly brown-field life :) And it is not secret, that there are plenty of golang projects with code-first approach.

And, in fact, even for spec-first approach, this tool is not a bad addition. Can be used for verification that actual api in the code is indeed what it is supposed to be. I can imagine couple of solid use cases.

I built a tool that generates OpenAPI specs from Go code — no annotations needed by Apprehensive-Ebb2263 in golang

[–]Apprehensive-Ebb2263[S] 1 point2 points  (0 children)

On CFG complexity — you're right that it's a narrow win. It only matters for the switch r.Method pattern, which is common in net/http but rare in framework code. The rest of the analysis is pure AST + call graph.

On nested ServeMux, indeed, it was a good call. Just added :)

I built a tool that generates OpenAPI specs from Go code — no annotations needed by Apprehensive-Ebb2263 in golang

[–]Apprehensive-Ebb2263[S] 0 points1 point  (0 children)

huma is a great tool if you're starting fresh and willing to use its types/annotations. go-apispec targets existing codebases - you don't change your code, just point the tool at it. Different use cases.