[Community Goal 2026] [S1] Migrate `@asyncapi/openapi-schema-parser` into the `parser-js`

[princerajpoot20]

Description

We have approval from the codeowners of openapi-schema-parser and parser-js.
More details here:
#322
asyncapi/parser-js#1194

We are proceeding with the merger.

Move @asyncapi/openapi-schema-parser into asyncapi/parser-js as packages/openapi-schema-parser/. Same npm package name and public API — no breaking change for consumers.

Action items

• Move code into parser-js (packages/openapi-schema-parser/)
• Update turbo.json / monorepo wiring for the new package
• Point multi-parser at the workspace package (today it still depends on the published npm version ^3.0.4)
• Sort out releases so @asyncapi/openapi-schema-parser publishes from parser-js
• Add a spec for openapi-schema-parser (see below)
• Update other relevant files as needed, such as the README.

CODEOWNERS: no change needed — all openapi-schema-parser codeowners already have full access to parser-js.

Optional: verify the first release from the monorepo publishes correctly.

Out of scope: Archiving the openapi-schema-parser repo.

Spec

The reason we are consolidating these repos — and the broader community goal of auditing — is to improve repo health and maintainability, bring on more maintainers, and eventually reduce maintainer burnout.

As part of that, we are adding specs in these repos. Specs act as a source of truth for contributors, and more importantly give AI context about the package. That should help anyone developing here, whatever approach they follow: pure vibe coding, pure spec-driven, or a mix of both.

Notes on references inside parser-js

What does need updating: packages/multi-parser/package.json currently has "@asyncapi/openapi-schema-parser": "^3.0.4" (npm). After migration it should use the local workspace package (same pattern as "@asyncapi/parser": "*"), so builds/tests resolve to packages/openapi-schema-parser instead of registry.npmjs.org.

Docs/README links that currently point at the standalone GitHub repo can be updated to the monorepo path as a follow-up.

References

• https://github.com/asyncapi/openapi-schema-parser
• https://github.com/asyncapi/parser-js

[princerajpoot20]

I will be working on this under microgrant program.

[AceTheCreator]

@princerajpoot20, I have a few clarification questions:

1. Browser compatibility: How does this change affect the browser module of the parser? Will it break the in-browser environments supoprt?

2. Scope of the change: Are you moving the code into the repo as-is, with no changes to how it's used? I'm asking because the parser has Node.js dependencies, and I want to confirm the usage stays consistent with what's documented in the Custom Schema Parsers section.

3. Terminology: When you say "migrate," what exactly do you mean? Are you deprecating the old approach, or is this purely additive?

[princerajpoot20]

@AceTheCreator

1. No, this does not affect the parser browser module. We're only moving where the OpenAPI package's source code lives. We're not bundling it into the parser's browser build. OpenAPI remains a separate package, just as it is today.
2. Yes - this is a code relocation with no change in usage. Consumers will still install @asyncapi/openapi-schema-parser and register it as documented under Custom Schema Parsers. We are moving the code as-is. only its location is changing. The functionality remains exactly the same.
3. Migrate means moving the source code into parser-js. The package name remains the same - this is not a deprecation of the consumer approach.

In short, nothing is changing for consumers. Everything remains exactly as it is today for them.

[AceTheCreator]

Okay. Thanks for the clarifiction @princerajpoot20