feat(generate): allow generating Server URL boilerplate #2002
Conversation
Kusari Analysis ResultsAnalysis for commit: d90d71a, performed at: 2025-06-14T13:14:45Z • • Recommendation✅ PROCEED with this Pull Request Summary✅ No Flagged Issues Detected All values appear to be within acceptable risk parameters. The PR introduces no dependency changes and contains only one low-impact, low-likelihood security issue related to using text/template instead of html/template. This issue poses minimal risk in the context of a code generator (not a web application directly serving content), making it unlikely to create a real XSS vulnerability. No secrets, critical vulnerabilities, or workflow issues were detected in the analysis. Found this helpful? Give it a 👍 or 👎 reaction! |
|
Kusari PR Analysis rerun based on - e12ddc5 performed at: 2025-06-14T12:52:05Z - link to updated analysis |
When working with a client generated by `oapi-codegen`, it can be a little awkward to manage changing URLs for the `client.WithBaseURL`. Although it's possible to manage these ourselves - with hardcoded values - it can be handy to have this pre-generated, especially if the input spec already defines `$.servers`. This introduces the capability to opt-in to the generation (as we try to make all changes opt-in where possible) of these. This is a little more complicated than ""just"" generating constants, as a Server object could introduce a templated URL. This requires we: - generate the `const`s for non-templated URLs - generate the more in-depth boilerplate for templated URLs We try and do most of the generating in the template, rather than in Go code, although it's not straightforward to generate the method parameters for the generated function (i.e. `NewServerUrlTheProductionAPIServer`) so we create a `genServerURLWithVariablesFunctionParams` function. We'll leave a few cases of additional validation or handling of edge cases to a follow-up.
|
Kusari PR Analysis rerun based on - d90d71a performed at: 2025-06-14T13:14:45Z - link to updated analysis |
I noticed this while integrating with [0], that it may be nicer to provide a `name` for the URL. [0]: oapi-codegen/oapi-codegen#2002
I noticed this while integrating with [0], that it may be nicer to provide a `description` for the URL. [0]: oapi-codegen/oapi-codegen#2002
When working with a client generated by
oapi-codegen, it can be alittle awkward to manage changing URLs for the
client.WithBaseURL.Although it's possible to manage these ourselves - with hardcoded values
spec already defines
$.servers.This introduces the capability to opt-in to the generation (as we try to
make all changes opt-in where possible) of these.
This is a little more complicated than ""just"" generating constants, as
a Server object could introduce a templated URL.
This requires we:
consts for non-templated URLsWe try and do most of the generating in the template, rather than in Go
code, although it's not straightforward to generate the method
parameters for the generated function (i.e.
NewServerUrlTheProductionAPIServer) so we create agenServerURLWithVariablesFunctionParamsfunction.We'll leave a few cases of additional validation or handling of edge
cases to a follow-up.