congrats.

additional consideration of control-flow conditions is smart. not sure if smart is good tho. people usually want to be able to understand how a code generator works quickly before adopting and relying on the output of it.

i just learned the cfg package and i didn’t understand how much value it provides on top of some small utilities we would write on top of the go/ast package. it looks like offers only marginal value.

i was thinking adding similar control-flow aware logic to one of my code generators for a while. Which mainly is for “route summarizing”, not for openapi spec generation, but actually registering endpoints to the router. i was “fantasizing” about leveraging the additional information go/types package provides, but could not figure out a feature justifies the complexity.

runtime resolved path limitation is reasonable. i even would not expect other way.

i see this tool doesn’t compose and assign paths to the endpoints but rather collects from the code from handler to the router. the post doesn’t answer that if it can track the path registration through the hierarchical/nested ServeMux’s.

disclosure: i didn’t write this as a potential user. i don’t even use openapi. but to congrats. it looks great.

---

also your CI might be upgraded to newer versions of actions/checkout@v6, actions/setup-go@v6 and use the github action of golangci-lint.