Fix regression resolving $ref with sibling definitions

[jonasschmidt]

Summary

Fixes #101 — a regression between v0.10.2 and v0.11.x where resolving a schema whose node contains both $ref and sibling definitions raised InvalidReferenceError.

The $ref resolution clause in ExJsonSchema.Schema rebuilt the node as %{"$ref" => ref}, discarding every sibling key — including definitions. As a result any pointer into a sibling definitions (e.g. #/definitions/foo alongside a $ref) could no longer be resolved:

ExJsonSchema.Validator.validate(
  %{"$ref" => "#/definitions/foo", "definitions" => %{"foo" => %{"type" => "string"}}},
  5
)
# v0.11.4: ** (ExJsonSchema.Schema.InvalidReferenceError) invalid reference #/definitions/foo
# fixed:   {:error, [{"Type mismatch. Expected String but got Integer.", "#"}]}

Changes

• Resolve the full schema for a $ref node instead of stripping siblings, so definitions (and other structural keys) survive resolution.
• Keep the $ref clause ahead of the $id/id clauses so a sibling $id still does not change the base URI, preserving draft 4/6/7 semantics ($ref prevents a sibling $id from changing the base uri in the official suite).
• Sibling validation keywords are still ignored at validation time via Validator.validation_errors/4, so draft 4/6/7 "$ref overrides siblings" behavior is unchanged.

Tests

• schema_test.exs: resolving a $ref to a sibling definition succeeds.
• validator_test.exs: validation via a $ref with a sibling definition (root and nested) reports the correct error.
• Full suite (incl. draft 4/6/7 official test suites) passes: 3317 tests, 0 failures.

Test plan

• mix test

Made with Cursor

[coveralls]

coverage: 91.806%. remained the same — fix/ref-sibling-definitions into master