feat: add extensions from extensions catalog to schema

[sambhavgupta0705]

This PR is part of asyncapi mentorship program
related issue: #280

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[smoya]

@sambhavgupta0705 can you please link the issue related with this PR so people can know about it? Thanks!

[sambhavgupta0705]

@smoya sorry for the late reply
here is the issue link #280

[derberg]

I opened a PR to your fork with enhancements. It was more complex than I thought and in depts knowledge of JSON Schema was needed.

Before you merge my PR into your fork (that will automatically update this PR):

• please familiarize with changes in bundler script. They were necessary if we are about to treat extensions the same as bindings
• info schema is not an allOf because I believe best practice is already defined by bindings, where bindings have separate definition schema that accommodates all bindings for a given keyword. So this is why I suggest infoExtensions.json that will be responsible to keep a list of all info extensions, so we do not "pollute" the main info schema.

so yeah, proposal is that whenever there is a new extension in the catalog, for any part of the AsyncAPI document, like server or operations or whatever - extension should never be added inside the operations but operations should be modified into allOf and there needs to be a new operationsExtensions.json created and new schema of new extension must be listed there.

Your job now is to now add to README a section where you explain a requirement on how extension schema should be added to the repo:

• where to put extensions:
  • what folder
  • what versioning means
  • extension name in folder structure
  • schema always in file called schema.json
• that there needs to be a corresponding definition that relates to AsyncAPI object, like info and that it must have Extensions suffix. Basically point in readme to x-x as example

[derberg]

the structure must change a bit, as you noticed, we initially forgot about versioning, so good you added it, but there is one more thing - each extension like in case of bindings have be independently released so:

extensions/x/0.1.0/schema.json - this is the path we should have, folder with extension name and then version and each version has given version of the schema - this is why we can have always one filename as well - schema.json

[derberg]

@sambhavgupta0705 one more thing, changes that I propose in my PR, I tested them locally after bundling schema, converting test yaml file from repo to v3 and adding below:

# yaml-language-server: $schema=/Users/wookiee/sources/asyncapi-node/schemas/3.0.0-without-$id.json
asyncapi: 3.0.0
info:
  # as you can see above locally I was using bundled local schema as yaml language, and below usage of x-x was shown as valid, and when I was using numbers I was getting errors
  x-x: MyTwitterProfile
  title: Streetlights Kafka API
  version: 1.0.0
  description: |-
    The Smartylighting Streetlights API allows you to remotely manage the city
    lights.
    ### Check out its awesome features:
  
    * Turn a specific streetlight on/off 🌃  
    * Dim a specific streetlight 😎
    * Receive real-time information about environmental lighting conditions 📈
  license:
    name: Apache 2.0
    url: 'https://www.apache.org/licenses/LICENSE-2.0'

[sambhavgupta0705]

@sambhavgupta0705 one more thing, changes that I propose in my PR, I tested them locally after bundling schema, converting test yaml file from repo to v3 and adding below:

can you please explain this a little more whenever you get time @derberg

[derberg]

@sambhavgupta0705 I mean that this is how I tested to make sure my changes produce a schema that is a valid schema

please also extend this PR by adding https://github.com/asyncapi/cli/blob/master/.sonarcloud.properties file, and making sure that whatever is in tools is ignored

[derberg]

@sambhavgupta0705 ready for final review?

[sambhavgupta0705]

@derberg yes it is

[sambhavgupta0705]

Done @derberg 🚀

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[derberg]

@dalelane @char0n @fmvilas @smoya

please have a look at this one - it introduces a way of adding schemas of extensions into official json schema

of course not just any random extension can be added here, but only extensions that are contributed to https://github.com/asyncapi/extensions-catalog. This should encourage community to share extensions.

and yeah, unfortunate is that the first extension we have is from old times when Twitter was Twitter, so the new extension is called x which looks strange and people will use it as x-x 😆 blame Musk

[derberg]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 6.0.0-next-major-spec.17 🎉

The release is available on:

• npm package (@next-major-spec dist-tag)
• GitHub release

Your semantic-release bot 📦🚀