Update module github.com/danielgtaylor/huma to v2 #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.14.3
->v2.32.0
Release Notes
danielgtaylor/huma (github.com/danielgtaylor/huma)
v2.32.0
Compare Source
Overview
HTTP HEAD Convenience Function
A convenience function was added for HTTP HEAD requests.
Stop HTML-Escaping JSON
HTTP API usage would rarely need to HTML-escape responses, so this default JSON marshaling behavior has been turned off. If you would like to keep the behavior, you can do so by modifying the
huma.Config.Formats
map. For example, error messages are now more readable:expected number \u003e= 10
expected number >= 10
Better Integer Validation
A new validation check has been added to present a better error message to the user when an integer is required but a floating point value like
1.5
is passed in. This now results in anexpected integer
message instead of a JSON unmarshal error.Groups + Convenience Function Improvements
Groups and convenience functions like
huma.Get
now play better together. Groups will regenerate the operation ID and operation summary iff those values were auto-generated and have not been modified. This works for groups of groups as well. The following are equivalent:If you prefer full control over the operation ID and summary, use
huma.Register
instead. You can still use group operation modifiers and convenience modifiers which modify the operation ID and/or summary and, if modified, they will not get regenerated. You can also disable generation by changing or unsetting the operation's_convenience_id
and_convenience_summary
metadata fields which are added by convenience functions likehuma.Get
/huma.Put
/etc.What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.31.0...v2.32.0
v2.31.0
Compare Source
Overview
Go 1.24
omitzero
Support!Huma now supports Go's new JSON
omitzero
feature out of the box, treating it similar to the existingomitempty
in terms of making fields optional. The updated rules for optional fields now look like this:omitempty
, it is optional.omitzero
, it is optional.required:"false"
, it is optional.required:"true"
, it is required.See https://huma.rocks/features/request-validation/#optional-required for more info.
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.30.0...v2.31.0
v2.30.0
Compare Source
Overview
Sponsors
A big thank you to our new sponsor:
Groups
Huma now supports groups, which port over much of the functionality from @cardinalby's excellent https://github.com/cardinalby/hureg library (thank you for that work!). This enables creating groups of operations with the same path prefixes, middleware, operation modifiers, and transformers. Typical usage might look like this:
See https://huma.rocks/features/groups/ for more details.
Context Unwrapping
Due to many user requests, it is now possible to "unwrap" a router-specific context into its constituent router-specific representation. Each adapter package now has an
Unwrap(huma.Context) T
function that will return either a request/response pair or that router's own context type, allowing you to effectively escape Huma in router-agnostic middleware & resolvers.Example usage:
While generally not recommended, this can help you to use router-specific middleware as you migrate large existing projects to Huma, or just escape Huma's abstractions when they no longer make sense for your use-case. Sometimes the best library is the one that gets out of the way.
See https://huma.rocks/features/middleware/#unwrapping for more details.
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.29.0...v2.30.0
v2.29.0
Compare Source
Overview
Support More Multipart Form Values
This enabled the use of fields with arbitrary types in the form which will get parsed & validated for you:
Better Auto-patch Support with Sub-routers
The auto-patch functionality now tries to find a common path prefix so it's possible to do stuff like this and have the generated
PATCH
operation function correctly:Custom Param Type Enhancements
Two new interfaces enable some additional advanced customization enhancements when creating operation input parameters:
These can be used like so:
Fix Panic from External Schema
It's possible to use the default schema transformers now with custom external schemas without causing a panic. For example:
Note: external schemas are not validated and are just there for informational purposes and to help with client generation.
Fiber Fixes
A major rework of the
humafiber
adapter was done in #725. This ensures tests are run with the-race
detector and fixes a race that was present in the Fiber adapter. It should be much more stable now.Deep Object Support for Params
Params now support the OpenAPI
deepObject
style, enabling e.g. query params to send structured input in that style.Example request:
Other fixes
Body
field is present.What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.28.0...v2.29.0
v2.28.0
Compare Source
Overview
Upgraded Documentation
Stoplight Elements has been upgraded to the latest version.
Others
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.27.0...v2.28.0
v2.27.0
Compare Source
Sponsors
A big thank you to our new sponsors:
Consider sponsoring the project!
Overview
Write Errors & Warnings to Stderr
When writing custom commands that output to stdout, sometimes an error or warning can be generated by Huma, which could add unwanted output to stdout. This has been updated to use stderr so it is easier to differentiate. This is useful for an
openapi
command that dumps the OpenAPI document to stdout as it is now safe to redirect it to a file even if warnings are generated.Better Handling of Embedded Header Fields
When headers are embedded in the output struct they are now properly referenced in the documentation and the parent embedded struct itself is ignored (previously it would include the headers twice). For example, this now works as expected:
Fiber
UserContext
SupportWhen using the Fiber adapter and getting items from the context it now first checks Fiber's
UserContext
before checking the underlying context for the value. This makes Huma easier to use with Fiber and Fiber-specific middleware. No change in behavior is needed, things should Just Work™️.Remove Chi From Tests
The code has been refactored to remove reliance on Chi for the tests, simplifying the project overall and relying more on the standard library.
Fix Operation Callbacks
Operation callbacks mistakenly used the wrong type of
map[string]*PathItem
when it should really have beenmap[string]map[string]*PathItem
instead. The structure should look something like this, which is now supported properly to document asynchronous callbacks that your operation supports:Better Support for Embedded RawBody Field
It's now possible to embed the
RawBody
field and have things work. For example:ContentTypeFilter
Now Updates OpenAPIIf an operation output implements
ContentTypeFilter
, then this will be called with the default valueapplication/json
and the result used to build the OpenAPI document. For example this will result inapplication/ld+json
in the OpenAPI rather thanapplication/json
:Other Fixes
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.26.0...v2.27.0
v2.26.0
Compare Source
Overview
Better Marking of Visited Types
When looking for params, headers, defaults, and resolvers the Huma type traversal code now tracks previously visited types more narrowly, continuing to detect recursive loops while allowing multiple adjacent fields to use the same type. Before this fix it would ignore some fields. For example, this now works propertly to run the resolver on both
HomeAddress
andAwayAddress
:More Resilient Fast Q Value Selection
Several minor bugs have been fixed in the fast zero-allocation
q
value parsing for client-based content negotiation via theAccept
header. Values likea;,
no longer cause a panic. Several new tests were added to ensure robustness.No Longer Panic From Client Disconnect
When a client disconnects and a write to the socket results in an error, we now check if the context is
context.Canceled
and ignore it. This should not result in a panic as that has a negative impact on metrics and perceived service health. An attempt is made to tell thehuma.Context
that the response status code should be 499 Client Disconnected to help with metrics/logging middleware.Others
WriteErr
and ensureNewErrorWithContext
is used everywhere. This should be a no-op for library users.What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.25.0...v2.26.0
v2.25.0
Compare Source
Overview
Case-insensitive JSON
Since the standard library Go unmarshaler supports case-insensitive field matches, Huma has been updated to support this during validation as well to better support integration with legacy systems & clients. This behavior can be disabled by explicitly setting
huma.ValidateStrictCasing = true
(the default matches the standard library behavior). For example, given:If a client were to send
{"Value": "test"}
instead of{"value": "test"}
it will now pass validation and work. This also works for the built-in CBOR format as well.Support Scalar Pointers with Defaults
Defaults have become more useful by enabling the use of pointers for basic types to have default values attached. For example, given this input to an operation:
It's now possible to explicitly send
false
without the value being overridden by the default. The behavior seen by the handler code is this:true
true
false
false
null
/undefined
true
Since this is using the built-in mechanism to determine if a value was sent, there is no additional performance penalty for setting the default values in Huma.
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.24.0...v2.25.0
v2.24.0
Compare Source
Overview
Better Support of String Subtype Slice Params
It's now possible to use types based on
string
like you commonly see for enumerations as slice inputs to Huma operations.Better Support of non-Object Refs
Fixes a bug that prevented deliberate refs of nullable non-objects from being used due to a panic. It's now possible to do something like this to automatically add enum values from a type when generating the schema and use a
$ref
in the JSON Schema:Fix Empty Security Marshaling
The empty security object has semantic meaning in OpenAPI 3.x which enables you to override a global security setting to make one or more operations public. It's now possible to do so:
Expanded Adapter Interface
The
huma.Adapter
interface now has methods for getting the HTTP version and TLS info of the incoming request, which enables better tracing middleware using e.g. OpenTelemetry.Schema Transformers Automatically Call
schema.PrecomputeMessages()
Schema transformers may modify the schema in ways that precomputed messages & validation cache data are no longer valid. This change makes sure to recompute them if the schema has been modified, preventing potential panics.
Configurable Array Nullability
Huma v2.20.0 introduced nullable JSON Schema arrays for Go slices due to the default behavior of Go's JSON marshaler. This change resulted in some clients (e.g. Typescript) now needing to do extra checks even when the service is sure it will never return a
nil
slice. This release includes a way to change the global default Huma behavior by settinghuma.DefaultArrayNullable = false
. It is still possible to setnullable
on each field to override this behavior, but now it is easier to do so globally for those who wish to use the old (arguably less correct) behavior.Better SSE Support
This release includes some
http.ResponseController
behavior to unwrap response writers to try and get access toSetWriteDeadline
andFlush
methods on response writers. This prevents error messages from being dumped into the console and enables Gin SSE support for the first time with the Humasse
package. Most routers should Just Work ™️ with SSE now.Read-Only & Write-Only Behavior Clarification
The read and write-only behavior of Huma validation has been clarified in the docs. See https://huma.rocks/features/request-validation/#read-and-write-only to ensure it works as you expect.
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.23.0...v2.24.0
v2.23.0
Compare Source
Overview
Pointers for Non-Param Fields
It's now possible to use pointers for non-param fields in input structs without Huma complaining. For example, here the
User
is not a path/query/header param and is populated from theAuthorization
header value for use later:Hidden Field Validation
Hidden fields are now validated properly if they are present in the input. For example:
Prevent Overwriting Schema Validations
All validations now take the existing value of the validator as input when generating the schema, which means a
SchemaProvider
orSchemaTransformer
output won't get overwritten when generating schemas. This fixes a bug that was partially fixed but missed several important fields likepattern
.Non-Addressable Resolver
It's now possible to use non-addressable types which implement
Resolver
, such as custom primitive types as map keys. This is currently a little less efficient as a pointer to the type needs to be generated, but at least it is now possible and performance can be improved in the future.Use the Status Code from
NewError
When providing your own custom
huma.NewError
function, the resulting error's status code was ignored. This has been fixed to be used as the output status code, enabling the function to modify the status code before going out on the wire.NewError with a Context
It's now possible to replace
huma.NewErrorWithContext
so your error generation function has access to the underlying request context.NewWithPrefix & Servers
When using
humago.NewWithPrefix
and not providing any servers, a single server entry is now generated for you with the given prefix.Support
url.URL
ParametersYou can now use a URL as an input path/query/header parameter and it will be parsed/validated for you.
Request Body Generation Improvements
Like response body generation, the request body generation has been improved to generate missing pieces of the body OpenAPI structure. This enables you to easily e.g. add a description but have Huma still generate the JSON Schema for you. Example:
What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.22.1...v2.23.0
v2.22.1
Compare Source
Overview
This patch release fixes a bug where the order of operations when resetting a buffer could cause a race condition when putting that buffer back into the shared
sync.Pool
for re-use when reading in request bodies.What's Changed
Full Changelog: danielgtaylor/huma@v2.22.0...v2.22.1
v2.22.0
Compare Source
Sponsors
A big thank you to our new sponsor:
Overview
Minimum Go Version: 1.21
The minimum Go version has been upgraded to 1.21, in alignment with the official Go policy. This enables us to fix some critical vulnerabilities with optional dependencies via dependabot and allows the code to be updated to use newer packages like
slices
, modernizing the codebase.https://go.dev/doc/devel/release
Fixes Raw Body Race Condition
This release fixes a critical bug where you could run into a race condition using a shared buffer when accessing a request's
RawBody []byte
field. The buffer was getting returned to thesync.Pool
too early, resulting in multiple requests having concurrent access. For handlers which register needing access to theRawBody
field, returning the buffer to the pool is now deferred until after then entire handler has run, fixing the issue.Better
encoding.TextUnmarshaler
SupportSupport for types which implement
encoding.TextUnmarshaler
has been improved. The types are now treated as a JSON Schemastring
by default, making it easier to set up validation and defaults without needing to provide a custom schema viahuma.SchemaProvider
. Among other things this can be used for custom date/time types:Precompute Schema Validation
Schema validation messages are no longer required to be precomputed manually with a call to
schema.PrecomputeMessages()
as this now happens at operation registration time. This simplifies using custom schemas and makes it possible to define them inline with the operation.If you modify a schema after registration, you must still call
PrecomputeMessages()
manually to update the messages.Fix Nil Response Panic
If an operation is registered as returning a body and a handler mistakenly invokes
return nil, nil
(meaning no response, no error) this caused a panic as the body is required. This release changes that behavior to no longer panic, but instead return the operation's default status code instead.What's Changed
New Contributors
Full Changelog: danielgtaylor/huma@v2.21.0...v2.22.0
v2.21.0
Compare Source
Overview
Better Support for Default/Example in Custom Schemas
Fixes an issue where custom schemas could have values overwritten by the default instead of using the given value. For example:
Better Errors When Using Discriminators
OpenAPI supports using a discriminator field in schemas that use
oneOf
to determine which of the included schemas to validate against. Huma now uses this information to generate better error messages likeexpected required property color to be present
instead of just saying it expected one of the schemas to match. Also handles problems with the discriminator type and value mapping. Example https://go.dev/play/p/5gkNczNJ_jK:What's Changed
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.