René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"std-http-server: allow MiddlewareFunc to be emitted as a type alias","articleBody":"## Summary\n\nFor `std-http-server`, `MiddlewareFunc` is currently generated as a named function type:\n\n```go\ntype MiddlewareFunc func(http.Handler) http.Handler\n```\n\nThis makes the generated middleware type package-specific. In projects that split one OpenAPI spec into multiple generated packages, a shared middleware slice such as:\n\n```go\n[]func(http.Handler) http.Handler\n```\n\ncannot be passed directly into each generated package's `StdHTTPServerOptions.Middlewares`.\n\nEach generated package has its own distinct type, for example:\n\n```go\n[]core.MiddlewareFunc\n[]admin.MiddlewareFunc\n[]public.MiddlewareFunc\n```\n\nThat forces callers to write conversion helpers per generated package, even though the underlying middleware shape is the standard `net/http` middleware signature.\n\n## Proposal\n\nEither emit `MiddlewareFunc` as a type alias:\n\n```go\ntype MiddlewareFunc = func(http.Handler) http.Handler\n```\n\nor add a generator option that allows users to choose alias generation for middleware types.\n\n## Motivation\n\nThis would make generated `std-http-server` middleware easier to compose in applications that:\n\n- generate multiple packages from one or more OpenAPI specs\n- share the same `[]func(http.Handler) http.Handler` middleware chain across those generated servers\n- use dependency injection or shared route registration interfaces\n- want to avoid repetitive conversion helpers like:\n\n```go\nfunc toMiddlewares(mws []func(http.Handler) http.Handler) []gen.MiddlewareFunc {\n    out := make([]gen.MiddlewareFunc, len(mws))\n    for i, mw := range mws {\n        out[i] = mw\n    }\n    return out\n}\n```\n\nWith an alias, callers can pass the shared middleware slice directly while preserving the existing generated API shape.\n\n## Benefits\n\nThis reduces boilerplate and makes the generated `std-http-server` middleware API easier to use with normal Go `net/http` middleware.\n\nToday, when an application has multiple generated server packages, each package gets its own distinct `MiddlewareFunc` type. Even though every type has the same underlying signature, Go does not allow a `[]func(http.Handler) http.Handler` slice to be used as a `[]gen.MiddlewareFunc` slice. It also does not allow one generated package's middleware slice to be reused as another generated package's middleware slice.\n\nUsing an alias would let applications define middleware once:\n\n```go\nmiddlewares := []func(http.Handler) http.Handler{\n    requestIDMiddleware,\n    authMiddleware,\n    loggingMiddleware,\n}\n```\n\nand pass that same slice to every generated `std-http-server` package without conversion.\n\nThat matters most for larger services that split APIs into multiple generated packages but still need one consistent middleware chain for validation, auth, logging, tracing, and metrics. The alias keeps the generated API ergonomic while still documenting the expected middleware shape through the `MiddlewareFunc` name.\n\n## Compatibility\n\nChanging the type to an alias may be source-compatible for most users, but it is technically observable for users relying on `MiddlewareFunc` as a distinct named type.\n\nIf that compatibility risk is too high, a config option would preserve current behavior by default while allowing projects that need shared middleware composition to opt in.","author":{"url":"https://github.com/jay-babu","@type":"Person","name":"jay-babu"},"datePublished":"2026-05-02T20:29:57Z","url":"https://github.com/oapi-codegen/oapi-codegen/issues/2363"}