chore: upgrade to libopenapi v0.41.1 and github.com/pb33f/go-yaml - #324
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #324 +/- ##
=======================================
Coverage 98.27% 98.27%
=======================================
Files 75 75
Lines 9192 9203 +11
=======================================
+ Hits 9033 9044 +11
Misses 132 132
Partials 27 27
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Move to libopenapi v0.41.1, and with it from go.yaml.in/yaml/v4 to github.com/pb33f/go-yaml v0.1.0, pb33f's fork. libopenapi's models carry the fork's yaml.Node, so the validator has to use the same module. The package is still named yaml, so the change is the import path. jsonpath moves to v0.8.4 and testify to v0.1.1, which use the same module. libopenapi requires Go 1.26, so go.mod does too. CI's build job now reads the Go version from go.mod (checking out first so the file exists), and golangci-lint moves to v2.12, which is built with Go 1.26. Since libopenapi v0.39, a schema built from a component-level $ref reports the index of the file its content came from, while its root node stays the authored $ref node in the referring file. buildSchemaDocumentResources looked for that node in the wrong document and failed with "schema node was not found in its root document". It now finds the node in the schema's index or, failing that, in its parent proxy's index, which libopenapi documents as the file the $ref was written in. This fixes TestSingleSchemaCompilePreferred_ResolvedExternalReferenceUsesSingleSchemaCompiler and TestCompileSchemaForValidation_NestedResourceRenderFailure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
daveshanley
force-pushed
the
libopenapi-v0.41
branch
from
September 28, 2026 16:33
3fdf665 to
4a37d8f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Brings the validator up to libopenapi v0.41.1. That includes the move to
github.com/pb33f/go-yamland one fix for a libopenapi behavior change that broke two tests.Dependencies
Name__<dir>) when one file is referenced from bothallOfandpropertieslibopenapi#644 on top of v0.41.0.go.yaml.in/yaml/v4→github.com/pb33f/go-yamlv0.1.0, pb33f's fork. libopenapi's models carry the fork'syaml.Node, so the validator must use the same module. The package is stillyaml, so 23 files change their import path and nothing else.go.moddoes too.CI
go.mod. It was pinned to 1.25. Checkout now runs beforesetup-goso the file exists when setup-go reads it.golangci-lint run ./...reports 0 issues.Fix: referenced schemas and their root document
These two tests pass against libopenapi v0.38.6 and fail from v0.39 on:
TestSingleSchemaCompilePreferred_ResolvedExternalReferenceUsesSingleSchemaCompilerTestCompileSchemaForValidation_NestedResourceRenderFailureWhat changed in libopenapi. v0.39 started attributing schemas to the file their content came from. For a component-level
$ref,Schema().GetIndex()now names the target file (models.yaml). The schema's root node deliberately stays the authored$refnode in the referring file (openapi.yaml).Why the validator failed.
buildSchemaDocumentResourcessearched for that node in the target file's document. It wasn't there, so the function returnedschema node was not found in its root document.The fix.
schemaRootLocationlooks for the node in the schema's index first. If it isn't there, it tries the parent proxy's index, which libopenapi documents as the file the$refwas written in. The function then builds the resource set from whichever document holds the node. That restores the v0.38.6 resource layout: an entry pointer intoopenapi.yaml, plus the reachablemodels.yamlresource.Tests
go build,go vet,golangci-lintandgo test -race ./...all pass.TestSchemaRootLocationcovers the node being in the schema's own document, and being in no candidate document with a parent proxy that has no index.main(98.6%), and the previously uncovered blocks are unchanged.🤖 Generated with Claude Code