feat: create a parser plugin to support RAML 1.0 data types as a schema format

[GeraldLoeffler]

The AsyncAPI spec has been supporting RAML 1.0 data types as a RECOMMENDED schema format for some time: spec (https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#schema-formats-table . However, the CLI currently does not seem to use a parser plugin for this schema format (see https://asyncapi.slack.com/archives/CQVJXFNQL/p1637599807269900?thread_ts=1637599687.269800&cid=CQVJXFNQL): please add one.

[github-actions[bot]]

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.

[jonaslagoni]

Related parser plugin: https://github.com/asyncapi/raml-dt-schema-parser

[derberg]

hint for whoever will work on this:

• also add openapi and avro plugins
• this is how you register them https://github.com/asyncapi/generator/blob/master/lib/generator.js#L60-L62

[starlightknown]

hello, wanted to confirm changes before I make a PR @derberg :

[derberg]

@starlightknown omg, so sorry, I just noticed this by accident when I was doing a review of good first issues 😞

please always open a PR when you have something already, just mark it as draft. It is really easy to miss some comment in some issue. Still not a good excuse 😄 sorry 😞

The changes you suggest are good, but this is not the only place where we need it. The fetch-asyncapi-example.js is a script that we run during build. There is also a need to make a change in the CLI itself. Now, when I look at the code now, months after creation of this issue, things are getting more complicated IMHO, it is not that trivial anymore because, I see that in code we user parser directly already in diff.ts, validate.ts and models.ts. So the change you have in the screenshot would have to be duplicated in 3 different files, which already rings a bell that this is not the best way to do it. IMHO to solve this issue, a wrapper around parser should be introduced, and diff.ts, validate.ts and models.ts should be refactored to use the new wrapper.

@boyney123 @magicmatatjahu @Souvikns thoughts?

[magicmatatjahu]

ParserJS is a single instance lib so we should only create parser.ta file with that code:

import { parse, registerSchemaParser } from '@asyncapi/parser';
import openapiSchemaParser from '@asyncapi/openapi-schema-parser';
import avroSchemaParser from '@asyncapi/avro-schema-parser';
import ramlDtSchemaParser from '@asyncapi/raml-dt-schema-parser';

registerSchemaParser(openapiSchemaParser);
registerSchemaParser(avroSchemaParser);
registerSchemaParser(ramlDtSchemaParser);

export { parse } 

and reuse that parse function in other places.

[github-actions[bot]]

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

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 :heart:

[asyncapi-bot]

:tada: This issue has been resolved in version 0.29.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: