Integrate the extension catalog with the JS parser

[sambhavgupta0705]

In regards of Mentorship issue Extension Catalog we need to validate the extension with parser-js,regarding I would like to know in which folder should I place the models of the extension.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

@smoya @magicmatatjahu @jonaslagoni

folks do you have an opinion what would be the best place for such to place? It would be also similar with bindings.

what I guess is that that we need a clear idea:

• where to place models for extensions
• where to place validation code for extensions using spectral

[jonaslagoni]

folks do you have an opinion what would be the best place for such to place? It would be also similar with bindings.
I have no idea.

Not really no, cause we still need to enable custom extensions and bindings, which means we can't really force types in any way 🤨

I would look into the different solutions and propose them so we can see what's possible. Without deep diving into it, Its a shot in the dark 🤷

[derberg]

enable custom extensions and bindings, which means we can't really force types in any way 🤨

sorry, what do you mean?
also, I guess by custom extensions you mean the same as extension catalog but "private", but extension catalog is easier, as these are official extensions, do not require fancy solution with some custom extensions packages (like custom schema parsers). So MVP idea with extension catalog is to treat it as part of parser - as extensions from extension catalog are official extensions

[smoya]

Current Parser-API does not support any model for any extension or bindings.
If we want to support them via the API of the parser, we need to first work on the Parser-API repository and get into an agreement there.

The alternative would be to keep it like it is today but crafting some sort of external parser for those extensions (maybe in the extensions-catalog repo. For example, a signature like function TwitterExtension(document: AsyncAPIDocument): TwitterExtensionModel so in that way it is not coupled with the parser.

I think both solutions have pros and cons that should be evaluated though.

[sambhavgupta0705]

Current Parser-API does not support any model for any extension or bindings.
If we want to support them via the API of the parser, we need to first work on the Parser-API repository and get into an agreement there.

The alternative would be to keep it like it is today but crafting some sort of external parser for those extensions (maybe in the extensions-catalog repo. For example, a signature like function TwitterExtension(document: AsyncAPIDocument): TwitterExtensionModel so in that way it is not coupled with the parser.

@derberg which method seems good to you ?

[derberg]

both are complex enough @sambhavgupta0705 so that we need to figure out what next, as it might be to much for mentorship

[sambhavgupta0705]

okay @derberg
atm I don't have that much idea of parser so can't say anything about this

[smoya]

okay @derberg atm I don't have that much idea of parser so can't say anything about this

I'm open to answer all your questions as I did through Slack via DM (Still waiting for your feedback btw).
I encourage you to keep into the loop; I'm happy to guide you.

For the record:

Sergio Moya
:v3:  [13:24](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988683762959)
The JSON Schema documents are for validating purpose. They validate basic structure of the AsyncAPI document.
[13:25](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988728341559)
The Parser-JS parses the AsyncAPI documents. That includes first a validation of them using those JSON Schema files, among other checks the Parser. performs
[13:25](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988758569939)
Once validated, it gives you a Javascript object that represents the parsed document, where you can access all the objects of an AsyncAPI document, such as Channels, Operations, etc.
[13:26](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988770037739)
For example, document.channels()
[13:28](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988882340369)
The current Parser-JS API follows the [Parser-API](https://github.com/asyncapi/parser-api/blob/master/docs/api.md), which is just a plain text document that defines which API the parser should expose to their users. For instance, document.channels()  is documented in the Parser-API [here](https://github.com/asyncapi/parser-api/blob/master/docs/api.md#asyncapidocument) as channels(): Channels
[13:28](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988918759979)
Meaning, that method should return a Channels object, which is also documented in the Parser-API: https://github.com/asyncapi/parser-api/blob/master/docs/api.md#channels
[13:28](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988922954919)
Etc
[13:29](https://asyncapi.slack.com/archives/D057P2Q6N03/p1702988972375209)
Now, if you want to introduce a change in the schema, like a new object and you want the users to be able to access that, you will need to expose it through the Parser-API and then implement it in the Parser-JS.

[sambhavgupta0705]

yes @smoya
Thanks for answering all my questions 😄

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[sambhavgupta0705]

still relevant

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[sambhavgupta0705]

Still relevant