Skip to content

feat(reference): add support for AsyncAPI 3.1.0 - #5263

Merged
robert-hebel-sb merged 2 commits into
feat/asyncapi-3.1.0/phase-2from
feat/asyncapi-3.1.0/phase-3
Oct 21, 2026
Merged

robert-hebel-sb merged 2 commits into
feat/asyncapi-3.1.0/phase-2from
feat/asyncapi-3.1.0/phase-3

Conversation

@robert-hebel-sb

Copy link
Copy Markdown
Contributor

Phase 3 of 4 for AsyncAPI 3.1.0 support: apidom-reference.

Depends on #5262 (stacked; base is feat/asyncapi-3.1.0/phase-2).

Changes

  • The asyncapi-json-3 / asyncapi-yaml-3 parsers and the asyncapi-3 dereference strategy take their media types from apidom-ns-asyncapi-3, so 3.1.0 documents are handled without source changes.
  • README: added the asyncapi-json-3 and asyncapi-yaml-3 parser sections and the asyncapi-3 dereference strategy section with their 3.0.0 and 3.1.0 media types (AsyncAPI 3 was only mentioned in the execution order examples so far).
  • Parser tests and fixtures for asyncapi-json-3 / asyncapi-yaml-3 bumped to 3.1.0; canParse also asserts the 3.0.0 media type.
  • AsyncAPI 3 dereference fixtures bumped to "asyncapi": "3.1.0" (116 files); schemaFormat values with version 3.0.0 are kept.
  • New dereference fixtures for ROS 2 server and operation bindings referenced from components. ROS 2 binding fields can't hold Reference Objects, so the dereference visitor is unchanged.

Verification

  • build / typescript:check-types / lint / test: pass (1237 tests)
  • grep -c "version=3.1.0" README.md > 0
  • verify-urls: 0 broken

Known gaps

  • none

🤖 Generated with Claude Code

The AsyncAPI 3 parsers and dereference strategy take their media types from
apidom-ns-asyncapi-3, so they handle 3.1.0 documents without source changes.
Document the asyncapi-json-3 and asyncapi-yaml-3 parsers and the asyncapi-3
dereference strategy with their 3.0.0 and 3.1.0 media types in the README,
which did not list AsyncAPI 3 yet.

Bump the AsyncAPI 3 parser and dereference fixtures to 3.1.0, keep a 3.0.0
media type check in the parser tests, and add dereference fixtures for ROS 2
server and operation bindings. ROS 2 binding fields cannot hold Reference
Objects, so the dereference visitor needs no change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@robert-hebel-sb
robert-hebel-sb force-pushed the feat/asyncapi-3.1.0/phase-3 branch from bdf8986 to 9f8ab2f Compare October 19, 2026 08:49
assert.deepEqual(toValue(actual), expected);
});
});
context('given ROS 2 binding in Operation Object', function () {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this test is a bit redundant, considering that all bindings work the same way 🤔 If we want to keep it, maybe we should instead add it to the existing fixtures, as that would test all paths (components, operation trait, operation), instead of just operation? But IMO it's not needed at all. Same goes for Server Bindings.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed & removed

Dereferencing resolves the $ref at the bindings container level and
never inspects binding values, so ROS 2 follows the same path as the
existing fixtures.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@robert-hebel-sb
robert-hebel-sb merged commit ce9881e into main Oct 21, 2026
9 checks passed
@robert-hebel-sb
robert-hebel-sb deleted the feat/asyncapi-3.1.0/phase-3 branch October 21, 2026 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants