Inline strict middleware typedefs#2271
Conversation
|
closes #2275 This PR would be able to fix the above issue aswell. |
mromaszewicz
force-pushed
the
fix/issue-2270
branch
from
d42c64a to
bc5e7c3
Compare
Replace type aliases to runtime/strictmiddleware/* packages with inline
type definitions in all strict server templates. This removes the
unnecessary runtime dependency for StrictHandlerFunc and
StrictMiddlewareFunc, and updates interface{} to any in the fiber
template for consistency.
Closes oapi-codegen#2270
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
mromaszewicz
force-pushed
the
fix/issue-2270
branch
from
bc5e7c3 to
79476ea
Compare
Greptile SummaryThis PR replaces type aliases to the The inline signatures correctly match those in the runtime packages ( Confidence Score: 4/5Safe to merge; all inlined signatures correctly match the original runtime package types, and the only finding is a cosmetic blank-line inconsistency in the fiber template. No logic bugs or security issues. The change from type aliases to type definitions is intentional per the PR description and the inline signatures are verified against the runtime package. The sole comment is a P2 style suggestion, leaving a ceiling of 4/5. No files require special attention, though reviewers should note the alias→definition semantic shift may require migration notes in the changelog for users who reference the runtime package types directly in their middleware code.
|
| Filename | Overview |
|---|---|
| pkg/codegen/configuration.go | Removes all strictmiddleware/* package imports from RouterImports() since the type definitions are now inlined in templates; clean and correct removal. |
| pkg/codegen/templates/strict/strict-echo.tmpl | Replaces alias to strictecho.StrictEchoHandlerFunc with inline func(ctx echo.Context, request any) (any, error) — signature matches the runtime package exactly. |
| pkg/codegen/templates/strict/strict-echo5.tmpl | Inlines the echo v5 handler type using *echo.Context (correct — echo v5 Context is a struct, not an interface); consistent with existing pointer usage throughout the template. |
| pkg/codegen/templates/strict/strict-gin.tmpl | Inlines gin handler types with *gin.Context; matches the original StrictGinHandlerFunc signature from the runtime package. |
| pkg/codegen/templates/strict/strict-http.tmpl | Inlines net/http handler type with (ctx context.Context, w http.ResponseWriter, r *http.Request, request any); correct four-argument form matching StrictHTTPHandlerFunc. |
| pkg/codegen/templates/strict/strict-iris.tmpl | Inlines iris handler type with iris.Context (interface, no pointer needed); matches StrictIrisHandlerFunc signature. |
| pkg/codegen/templates/strict/strict-fiber.tmpl | Modernizes interface{} to any and removes a blank line between the two type declarations; fiber was already using inline types (no alias), so this is cosmetic only. |
Reviews (1): Last reviewed commit: "Inline strict middleware typedefs" | Re-trigger Greptile
mromaszewicz
added
the
☢️ breaking change
|
My only grip with this change is not being a type alias if the above was instead now, each server i generate does not need to have to worry about having separate types. I can just define |
|
Thanks, you're right, that is nicer. |
|
@mromaszewicz if we could do the same thing here: https://github.com/oapi-codegen/runtime/blob/main/strictmiddleware/nethttp/main.go, then I could remove the need of having an type alias on my side to share across packages. The same change of having an |
|
Since we are inlining those functions into the boilerplate now, do we even care about the ones in the runtime package? |
|
@mromaszewicz This is more just about the client experience. I have N servers that all generate the code for that in a monorepo. strictmiddleware.go package main
import (
"context"
"net/http"
)
type strictHandlerFunc = func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error)
type strictMiddlewareFunc = func(f strictHandlerFunc, operationID string) strictHandlerFuncusing my helper, i can do something like this func NewAuthorizationMiddleware(queries model.Querier, logger *slog.Logger) strictMiddlewareFunc {
return func(f strictHandlerFunc, operationID string) strictHandlerFunc {
return func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error) {
if isAuthorizationExemptOperation(operationID) {
return f(ctx, w, r, request)
}
return checkAuthorization(ctx, w, r, request, f, operationID, queries, logger)
}
}
}without the helper, I have to do this. func NewAuthorizationMiddleware(queries model.Querier, logger *slog.Logger) func(f func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error), operationID string) func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error) {
return func(f strictHandlerFunc, operationID string) strictHandlerFunc {
return func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error) {
if isAuthorizationExemptOperation(operationID) {
return f(ctx, w, r, request)
}
return checkAuthorization(ctx, w, r, request, f, operationID, queries, logger)
}
}
}I guess I can just pick one of the generated servers and use the type-alias from that but would be better if I could just import from 
Everything you see here is a separate strict server that is generated. The main reason for this setup is because we siloed each service instead of having one giant interface. If there is a better way of doing this then please let me know. type ServerInterface interface {
// (GET /{entity_id}/campaign/campaigns/{campaign_id}/workflows)
CampaignsListCampaignWorkflows(w http.ResponseWriter, r *http.Request, entityId int64, campaignId string, params CampaignsListCampaignWorkflowsParams)
// (GET /{entity_id}/campaign/customers/{loyalty_customer_id}/metrics)
CampaignsGetCustomerMetrics(w http.ResponseWriter, r *http.Request, entityId int64, loyaltyCustomerId int64)
// (GET /{entity_id}/campaign/customers/{loyalty_customer_id}/workflows)
CampaignsGetCustomerWorkflows(w http.ResponseWriter, r *http.Request, entityId int64, loyaltyCustomerId int64, params CampaignsGetCustomerWorkflowsParams)
// (POST /{entity_id}/campaign/message)
CampaignsSendMessage(w http.ResponseWriter, r *http.Request, entityId int64)
// (GET /{entity_id}/campaign/metric-definitions)
CampaignsListMetricDefinitions(w http.ResponseWriter, r *http.Request, entityId int64, params CampaignsListMetricDefinitionsParams)
// (GET /{entity_id}/campaign/segments)
CampaignsListSegments(w http.ResponseWriter, r *http.Request, entityId int64, params CampaignsListSegmentsParams)
// (POST /{entity_id}/campaign/segments)
CampaignsCreateSegment(w http.ResponseWriter, r *http.Request, entityId int64)
// (PATCH /{entity_id}/campaign/segments/{segment_id})
CampaignsUpdateSegment(w http.ResponseWriter, r *http.Request, entityId int64, segmentId string)
// (POST /{entity_id}/campaign/segments/{segment_id}/archive)
CampaignsArchiveSegment(w http.ResponseWriter, r *http.Request, entityId int64, segmentId string)
// (POST /{entity_id}/campaign/workflows/cancel)
CampaignsCancelWorkflows(w http.ResponseWriter, r *http.Request, entityId int64)
// (GET /{entity_id}/campaign/workflows/{workflow_id}/{run_id})
CampaignsGetWorkflowDetail(w http.ResponseWriter, r *http.Request, entityId int64, workflowId string, runId string)
// (GET /{entity_id}/campaign/{campaign_id}/condition-tree)
CampaignsGetConditionTree(w http.ResponseWriter, r *http.Request, entityId int64, campaignId string)
}type ServerInterface interface {
// (GET /health)
HealthCheck(w http.ResponseWriter, r *http.Request)
// (GET /{entity_id}/job-events)
JobEventsList(w http.ResponseWriter, r *http.Request, entityId int64, params JobEventsListParams)
// (GET /{entity_id}/jobs)
JobsList(w http.ResponseWriter, r *http.Request, entityId int64, params JobsListParams)
} |
|
I have a goal to eventually make the runtime package completely unnecessary: But, using the aliases vs typedefs in the generated code would let you just pick one of them, as you said, or just define that function type in your own code somewhere. It rarely changes. |
3 participants
Replace type aliases to runtime/strictmiddleware/* packages with inline type definitions in all strict server templates. This removes the unnecessary runtime dependency for StrictHandlerFunc and StrictMiddlewareFunc, and updates interface{} to any in the fiber template for consistency.
Closes #2270,#2275