Summary
In std-http-server + strict-server generation, StrictMiddlewareFunc is currently emitted as a package-local named function type:
type StrictHandlerFunc func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error)
type StrictMiddlewareFunc func(f StrictHandlerFunc, operationID string) StrictHandlerFunc
This makes each generated package's strict middleware type distinct, even though all generated packages use the same middleware shape.
Problem
Applications commonly build one shared strict middleware chain and pass it to multiple generated server packages.
When an API is split across multiple generated packages, that shared slice cannot be passed directly to each generated package's NewStrictHandlerWithOptions, because each package expects its own distinct []gen.StrictMiddlewareFunc.
This forces conversion or wrapping per generated package, even though the middleware signature is the same.
Proposal
Emit the strict HTTP handler and middleware types as raw function aliases:
type StrictHandlerFunc = func(ctx context.Context, w http.ResponseWriter, r *http.Request, request any) (any, error)
type StrictMiddlewareFunc = func(f StrictHandlerFunc, operationID string) StrictHandlerFunc
Alternatively, add a generator option that allows users to opt into alias generation for strict middleware types.
Benefits
This keeps strict middleware composition ergonomic for larger services that split OpenAPI generation into multiple packages while sharing one request pipeline for database state, auth, auditing, logging, tracing, and metrics.
It also aligns with the current generated-code direction of defining the strict HTTP middleware shape directly in generated output instead of depending on github.com/oapi-codegen/runtime/strictmiddleware/nethttp.
With raw function aliases, applications can define their own shared alias with the same signature:
type StrictMiddlewareFunc = 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)
and pass one middleware slice to every generated strict server package without boilerplate conversion helpers.
Compatibility
Changing these types to aliases may be source-compatible for most users, but it is technically observable for code relying on StrictHandlerFunc or StrictMiddlewareFunc as distinct generated named types.
If that is a concern, a config option would preserve current behavior by default while allowing projects that need shared strict middleware composition to opt in.
Summary
In
std-http-server+strict-servergeneration,StrictMiddlewareFuncis currently emitted as a package-local named function type:This makes each generated package's strict middleware type distinct, even though all generated packages use the same middleware shape.
Problem
Applications commonly build one shared strict middleware chain and pass it to multiple generated server packages.
When an API is split across multiple generated packages, that shared slice cannot be passed directly to each generated package's
NewStrictHandlerWithOptions, because each package expects its own distinct[]gen.StrictMiddlewareFunc.This forces conversion or wrapping per generated package, even though the middleware signature is the same.
Proposal
Emit the strict HTTP handler and middleware types as raw function aliases:
Alternatively, add a generator option that allows users to opt into alias generation for strict middleware types.
Benefits
This keeps strict middleware composition ergonomic for larger services that split OpenAPI generation into multiple packages while sharing one request pipeline for database state, auth, auditing, logging, tracing, and metrics.
It also aligns with the current generated-code direction of defining the strict HTTP middleware shape directly in generated output instead of depending on
github.com/oapi-codegen/runtime/strictmiddleware/nethttp.With raw function aliases, applications can define their own shared alias with the same signature:
and pass one middleware slice to every generated strict server package without boilerplate conversion helpers.
Compatibility
Changing these types to aliases may be source-compatible for most users, but it is technically observable for code relying on
StrictHandlerFuncorStrictMiddlewareFuncas distinct generated named types.If that is a concern, a config option would preserve current behavior by default while allowing projects that need shared strict middleware composition to opt in.