GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing github.com — std-http-server: allow MiddlewareFunc to be emitted as a type alias · Issue #2363 · oapi-codegen/oapi-codegen Open DescriptionSummaryFor type MiddlewareFunc func(http.Handler) http.Handler This makes the generated middleware type package-specific. In projects that split one OpenAPI spec into multiple generated packages, a shared middleware slice such as: []func(http.Handler) http.Handler cannot be passed directly into each generated package's Each generated package has its own distinct type, for example: []core.MiddlewareFunc []admin.MiddlewareFunc []public.MiddlewareFunc That forces callers to write conversion helpers per generated package, even though the underlying middleware shape is the standard ProposalEither emit type MiddlewareFunc = func(http.Handler) http.Handler or add a generator option that allows users to choose alias generation for middleware types. MotivationThis would make generated
func toMiddlewares(mws []func(http.Handler) http.Handler) []gen.MiddlewareFunc { out := make([]gen.MiddlewareFunc, len(mws)) for i, mw := range mws { out[i] = mw } return out } With an alias, callers can pass the shared middleware slice directly while preserving the existing generated API shape. BenefitsThis reduces boilerplate and makes the generated Today, when an application has multiple generated server packages, each package gets its own distinct Using an alias would let applications define middleware once: middlewares := []func(http.Handler) http.Handler{ requestIDMiddleware, authMiddleware, loggingMiddleware, } and pass that same slice to every generated That 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 CompatibilityChanging the type to an alias may be source-compatible for most users, but it is technically observable for users relying on If 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. Activity
MetadataMetadataAssigneesLabelsNo labels TypeProjectsMilestoneRelationshipsDevelopmentIssue actions |
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |