asyncapi / spec-json-schemas Goto Github PK

How to Reproduce

Using the test document in the CLI exposed a bug when servers define the following security:

      - type: openIdConnect
        openIdConnectUrl: openIdConnectUrl
        scopes:
        - 'some:scope:1'
        - 'some:scope:2'

Full document:

asyncapi: 3.0.0
id: 'urn:example:com:smartylighting:streetlights:server'
info:
  title: AsyncAPI Sample App
  version: 1.0.1
  description: This is a sample app.
  termsOfService: 'https://asyncapi.com/terms/'
  contact:
    name: API Support
    url: 'https://www.asyncapi.com/support'
    email: [email protected]
  license:
    name: Apache 2.0
    url: 'https://www.apache.org/licenses/LICENSE-2.0.html'
  tags:
    - name: e-commerce
    - name: another-tag
      description: Description...
  externalDocs:
    description: Find more info here
    url: 'https://www.asyncapi.com'
defaultContentType: application/json
servers:
  default:
    host: 'api.streetlights.smartylighting.com:{port}'
    protocol: mqtt
    description: Test broker
    variables:
      port:
        description: Secure connection (TLS) is available through port 8883.
        default: '1883'
        enum:
          - '1883'
          - '8883'
    security:
      - $ref: '#/components/securitySchemes/apiKey'
      - type: oauth2
        flows:
          implicit:
            authorizationUrl: 'https://example.com/api/oauth/dialog'
            availableScopes:
              'write:pets': modify pets in your account
              'read:pets': read your pets
        scopes:
          - 'write:pets'
      - type: openIdConnect
        openIdConnectUrl: openIdConnectUrl
        scopes:
        - 'some:scope:1'
        - 'some:scope:2'
  production:
    host: 'api.streetlights.smartylighting.com:{port}'
    pathname: /some/path
    protocol: mqtt
    description: Test broker
    variables:
      port:
        description: Secure connection (TLS) is available through port 8883.
        default: '1883'
        enum:
          - '1883'
          - '8883'
    security:
      - $ref: '#/components/securitySchemes/apiKey'
  withProtocol:
    host: 'api.streetlights.smartylighting.com:{port}'
    pathname: /some/path
    protocol: mqtt
    description: Test broker
    variables:
      port:
        description: Secure connection (TLS) is available through port 8883.
        default: '1883'
        enum:
          - '1883'
          - '8883'
    security:
      - $ref: '#/components/securitySchemes/apiKey'
channels:
  'smartylighting/streetlights/1/0/event/{streetlightId}/lighting/measured':
    address: 'smartylighting/streetlights/1/0/event/{streetlightId}/lighting/measured'
    messages:
      lightMeasured.message:
        payload:
          type: object
    servers:
      - $ref: '#/servers/production'
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
  'smartylighting/streetlights/1/0/action/{streetlightId}/turn/on':
    address: 'smartylighting/streetlights/1/0/action/{streetlightId}/turn/on'
    messages:
      publish.message:
        $ref: '#/components/messages/lightMeasured'
      subscribe.message.0:
        $ref: '#/components/messages/turnOnOff'
      customMessageId:
        messageId: customMessageId
        payload:
          type: object
      subscribe.message.2:
        payload:
          type: object
      subscribe.message.3:
        $ref: 'https://example.com/message'
    servers:
      - $ref: '#/servers/default'
      - $ref: '#/servers/production'
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
  customChannelId:
    address: 'smartylighting/streetlights/1/0/action/{streetlightId}/turn/off'
    messages:
      turnOnOff.message:
        $ref: '#/components/messages/turnOnOff'
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
    x-channelId: customChannelId
  'smartylighting/streetlights/1/0/action/{streetlightId}/dim':
    address: 'smartylighting/streetlights/1/0/action/{streetlightId}/dim'
    messages:
      dimLight.message:
        $ref: '#/components/messages/dimLight'
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
operations:
  lightMeasured:
    action: receive
    channel:
      $ref: >-
        #/channels/smartylighting~1streetlights~11~10~1event~1{streetlightId}~1lighting~1measured
    messages:
      - $ref: >-
          #/channels/smartylighting~1streetlights~11~10~1event~1{streetlightId}~1lighting~1measured/messages/lightMeasured.message
  'smartylighting/streetlights/1/0/action/{streetlightId}/turn/on.publish':
    action: receive
    channel:
      $ref: >-
        #/channels/smartylighting~1streetlights~11~10~1action~1{streetlightId}~1turn~1on
    messages:
      - $ref: '#/components/messages/lightMeasured'
  'smartylighting/streetlights/1/0/action/{streetlightId}/turn/on.subscribe':
    action: send
    channel:
      $ref: >-
        #/channels/smartylighting~1streetlights~11~10~1action~1{streetlightId}~1turn~1on
    messages:
      - $ref: '#/components/messages/turnOnOff'
      - $ref: >-
          #/channels/smartylighting~1streetlights~11~10~1action~1{streetlightId}~1turn~1on/messages/customMessageId
      - $ref: >-
          #/channels/smartylighting~1streetlights~11~10~1action~1{streetlightId}~1turn~1on/messages/subscribe.message.2
      - $ref: 'https://example.com/message'
  turnOnOff:
    action: send
    channel:
      $ref: '#/channels/customChannelId'
    messages:
      - $ref: '#/components/messages/turnOnOff'
  dimLight:
    action: send
    channel:
      $ref: >-
        #/channels/smartylighting~1streetlights~11~10~1action~1{streetlightId}~1dim
    security:
      - type: oauth2
        flows:
          implicit:
            authorizationUrl: 'https://example.com/api/oauth/dialog'
            availableScopes:
              'write:pets': modify pets in your account
              'read:pets': read your pets
        scopes:
          - 'write:pets'
    messages:
      - $ref: '#/components/messages/dimLight'
components:
  messages:
    lightMeasured:
      summary: >-
        Inform about environmental lighting conditions for a particular
        streetlight.
      payload:
        $ref: '#/components/schemas/lightMeasuredPayload'
    turnOnOff:
      summary: Command a particular streetlight to turn the lights on or off.
      payload:
        $ref: '#/components/schemas/turnOnOffPayload'
    dimLight:
      summary: Command a particular streetlight to dim the lights.
      payload:
        $ref: '#/components/schemas/dimLightPayload'
  schemas:
    lightMeasuredPayload:
      type: object
      properties:
        lumens:
          type: integer
          minimum: 0
          description: Light intensity measured in lumens.
        sentAt:
          $ref: '#/components/schemas/sentAt'
    turnOnOffPayload:
      type: object
      properties:
        command:
          type: string
          enum:
            - 'on'
            - 'off'
          description: Whether to turn on or off the light.
        sentAt:
          $ref: '#/components/schemas/sentAt'
    dimLightPayload:
      type: object
      properties:
        percentage:
          type: integer
          description: Percentage to which the light should be dimmed to.
          minimum: 0
          maximum: 100
        sentAt:
          $ref: '#/components/schemas/sentAt'
    sentAt:
      type: string
      format: date-time
      description: Date and time when the message was sent.
  securitySchemes:
    apiKey:
      type: apiKey
      in: user
      description: Provide your API key as the user and leave the password empty.
    flows:
      type: oauth2
      flows:
        implicit:
          authorizationUrl: 'https://example.com/api/oauth/dialog'
          availableScopes:
            'write:pets': modify pets in your account
            'read:pets': read your pets
    openIdConnect:
      type: openIdConnect
      openIdConnectUrl: openIdConnectUrl
    unusedFlows:
      type: oauth2
      flows:
        implicit:
          authorizationUrl: 'https://example.com/api/oauth/dialog'
          availableScopes:
            'write:pets': modify pets in your account
            'read:pets': read your pets
  parameters:
    streetlightId:
      description: The ID of the streetlight.

I have not checked whether it works for v2.

Expected behavior

Expected this to be a valid document.

What Dev Docs changes are you proposing?

There is a need to write down what is not in JSON Schema and we wrote custom validation code for it here https://github.com/asyncapi/parser-js/blob/master/lib/customValidators.js so it is transparent and clear what happens if someone decides to validate AsyncAPI document by using directly the AsyncAPI JSON Schema document.

Even our Parser JS is not yet 100% accurate with validation, so https://asyncapi.github.io/tck/asyncapi-parser_js_detailed_report.html should also be treated as source of truth

Code of Conduct

• I agree to follow this project's Code of Conduct

Reason/Context

This Issue is used to track changes needed to support AsyncAPI v3. As a code owner, please edit this list of TODO tasks in order to properly track the progress 🙂 Once this issue is closed it means that v3 is now fully supported in this library.

Although most changes are actually done here, because it's part of the release flow, there are still some outstanding issues.

Scope

• Allow Multi-format in JSON Schema files #370
• Release to production (master)

As we read in the specification about headers field for Message Object:

we validate it by the lines:

https://github.com/asyncapi/asyncapi-node/blob/master/schemas/2.1.0.json#L644-L657

However we should also validate the headers in the Message Trait Object:

https://github.com/asyncapi/asyncapi-node/blob/master/schemas/2.1.0.json#L885-L892

JSON Schemas for 2.0.0 and 2.1.0 should be updated.

in spec v3 we have new fields in Server Object:

• host
• pathname

in json schema we do not have any basic validation: https://github.com/asyncapi/spec-json-schemas/blob/next-major-spec/definitions/3.0.0/server.json#L15-L22

I think we should have at least some basic, that will fail if someone uses host the same way as it was with url, so localhost:3000/ws would be an error

JSON schema format keywords, might not be good, as hostname I think should be without port for example. I'm not 100% sure what formats from https://json-schema.org/understanding-json-schema/reference/string#built-in-formats we can reuse, thus suggesting patterns

Also in specification we are not so detailed and accurate, not pointing to standards like JSON Schema

cc @fmvilas that introduced a change in spec
cc @jonaslagoni release coordinator
cc @magicmatatjahu who I think introduced changes in json schemas
cc codeowners of the json schemas @dalelane @char0n @smoya

Reason/Context

There are specifically 2 schemas we wish to share among all versions.

• avroSchema_v1
• openapiSchema_3_0

To achieve this we need to do the following:

1. Move the common schemas to a common definition folder
2. Adapt the bundler (tools/bundler/index.js) to include these common definitions for all versions.

Reason/Context

Part of asyncapi/spec#584.

Description

Support security field containing an array of SecurityRequirement at Operation level.

As this is a good candidate to be in v2.3.0 release, the PR should be created from and targeting 2022-01-release branch.
Also 2.3.0.json should be the file where these changes should be added then.

As far as I see, the change we need to do is to add a new field called security into the operation definition. I think we can copy the one from the server found in https://github.com/asyncapi/spec-json-schemas/blob/2022-01-release/schemas/2.3.0.json#L192-L197

Now, we use normal type: string validation rule for server.host and server.pathname (in 3.0.0 version). We should add proper format (or create from scratch regex) to make validation more restricted (and better).

Describe the bug

I get Property name is not allowed.yaml-schema: AsyncAPI 3.0.0 schema.(0) when using name parameter in Security Scheme Object in v3 spec.

How to Reproduce

Link for document in Studio.

Expected behavior

As per docs we should be able to use the name parameter in the AsyncAPI document under Security Scheme Object.

Reason/Context

In order to follow an standard, but also ensuring any change won't break the JSON Schema documents, I suggest we add a new lint + validate action in our GH CI workflows that run on each PR and block the PR if JSON Schema files are not valid or following our requirements.

Description

Consider adding a new script to the package.json scripts section, that lints and validate JSON Schema files. Something like npm run lint or similar. Also could be included in npm test call. In that way, developers could run that command before pushing code but also during the execution of CI tests.

Run the following CI tasks on the JSON Schema files on each PR. It doesn't mean all of the following should run in different actions since most of them could be done just with one tool like Spectral.

• JSON linting
• Validate JSON Schema files structure
• [ ] Add some rules (Spectral?) for validating things like checking all definitions come with their examples and description fields. Any others are welcome as well. Not included for the bounty program

Detailed context

• This repository holds JSON Schema documents, which are used for validating AsyncAPI documents (transformed to JSON). The parsers mainly use those JSON Schemas (parser-js, for instance) to validate AsyncAPI documents.
• The JSON Schemas used by the parsers and any other tool that wants to validate AsyncAPI documents are located in the /schemas dir.
• Those schemas result from bundling several smaller schemas, the ones located under /definitions. Each of those small schemas usually refers to the validation related to just one object from the AsyncAPI spec, I.e., Message Object, Channel Object, etc.
• When people need to change those schemas, they do not modify them directly under /schemas but rather modify a particular (sometimes several of them) file under /definitions. That's done this way to help developers focus on what they want to change and not deal with a big file containing the whole JSON Schema doc for the entire specification.

Technical details that concern this issue:

• CI scripts that run on every Pull Request are these.
• The step that says Run linter is not about lining JSON Schemas but linting Javascript code. So, it has nothing to do with the work we want to do here.
• The latest step it runs is bundling all smaller schemas found under /definitions into the bundled big ones located in /schemas.
• We should validate those (/schemas), meaning our JSON Schema linting script should run after the generation of assets (the actual last step).

To illustrate the details above, here is a simple flow chart. Note that the script we should create is represented in the Validate schemas from /schemas step.

flowchart TD
    PR[PR] -->|Update schemas under /definitions| CI(CI / GH Actions)
    CI --> bundle(Bundle definitions into /schemas)
    bundle --> compile(Validate schemas from /schemas)
    subgraph The new action we should build
        compile -->result{Are schemas valid?}
        result -->|Yes| ok[OK - exit code 0]
        result -->|NO| ko[KO - print validation errors + exit code 1]
    end

Describe the bug

Currently, we default to our own AsyncAPI Schema Object regardless of what is present in the Message Object schemaFormat.

Expected behavior

Conditional matching the correct schema format to accurately validate schemas.

Apply the changes introduced by asyncapi/spec#935

Reason/Context

Few days ago 4.3.0 error happened.
I manually unpublished version 4.3 from npm but it was not removed, but marked as deprecated.

Problem is that if someone is using a project that depends on a project that depends on this package, they do not have influence over dependencies package.json, so if some project have ^4.1 in use, then 4.3 is anyway installed.

Temporary workaround is to use overrides in package.json to enforce 4.1

Description

Instead of making people use overrides feature from package.json, update docs and educate on request. @jonaslagoni have a good point that we could also release 4.3.1. More details: https://asyncapi.slack.com/archives/C34F2JV0U/p1683541443771049

Plan:

• I can manually just release whatever is under 4.2.1 as 4.3.1. Will run release pipeline from my local.
• Tag the same commit that has 4.2.1 as also 4.3.1
• Publish release in GitHub with proper description

@char0n @smoya @dalelane @fmvilas any objections?

Reason/Context

Following Go module major version suffixes creates complexity when releasing but also requires dependant libraries to manually update their go.mod and code in order to update to last major version (they need to change the import path in all the code).
More info https://go.dev/ref/mod#major-version-suffixes

Description

To find a solution, if possible that:

• Allows releasing major versions without the need of adding the suffix at the end of the module name. I.e. the v4 suffix in github.com/asyncapi/spec-json-schemas/v4 module name.
• Don't force dependant libraries to update all the imports of this module to replace the suffix to the last major version. That means the only change to do is in go.mod to update to the latest version.

Describe the Issue
There are some discrepancies with the machine readable version of the AsyncAPI specification version 2.0.0.

1. on line 571 additionalItems are defined when the schema type is object.
2. When additionalProperties are indeed allowed on many of the schemas and should follow the patternProperties, how come it is always sat to false 🤔? I.e. on line 10
3. On line 726 same as 1.
4. On line 782 missing type: [object, array].

Describe the bug

I just noticed that the operation traits https://github.com/asyncapi/spec-json-schemas/blob/master/definitions/2.5.0/operation.json#L13 can be defined with a double array:

{
      "type": "array",
      "items": {
        "oneOf": [
          {
            "$ref": "http://asyncapi.com/definitions/2.5.0/Reference.json"
          },
          {
            "$ref": "http://asyncapi.com/definitions/2.5.0/operationTrait.json"
          },
          {
            "type": "array",
            "items": [
              {
                "oneOf": [
                  {
                    "$ref": "http://asyncapi.com/definitions/2.5.0/Reference.json"
                  },
                  {
                    "$ref": "http://asyncapi.com/definitions/2.5.0/operationTrait.json"
                  }
                ]
              },
              {
                "type": "object",
                "additionalItems": true
              }
            ]
          }
        ]
      }
    }

I don't think this is the intended behavior as it allows you to define traits such as:

asyncapi: 2.5.0
info:
  title: Account Service
  version: 1.0.0
  description: This service is in charge of processing user signups
channels:
  user/signedup:
    subscribe:
      traits: [[{summary: 'test'}]]

Reason/Context

We should add the new 3.0 spec JSON Schema files so we can start to target PR's to the correct schema files.

Description

Blocked by #128

Describe the bug

Based on https://www.asyncapi.com/docs/reference/specification/v3.0.0-next-major-spec.12#componentsObject components section should allow operations in the components section.

How to Reproduce

parse an AsyncAPI file with:

...
components:
  operations: {}
...

Expected behaviour

It should allow me to have operations in the components section.
I am not sure if it's a spec issue or a parser issue. 🤔

Reason/Context

I’m trying to give some 💛 to https://github.com/asyncapi/parser-go. I just wanted to add support for the latest spec versions (it only supports 2.0.0).
In order to get the JSON Schema files for each spec, so it supports all of them, we would need to follow a similar approach @asyncapi/specs` package does (built from this repository).

Description

I suggest we just add a .go file into this repository similar to index.js.
I have a POC here https://github.com/smoya/spec-json-schemas/blob/feat/go/spec-json-schemas.go

Reason/Context

To make it more digestible and easier to pinpoint problems, I think it would make sense to split each definition into separate files.

Description

That said, I also see benefits in bundling all these separate definitions into one file. This way it remains easy to use in other settings, where you don't need all the separate files.

Reason/Context

After #128 it would be great to have a consistent way of defining how objects and references are defined.

In my opionion it would be better if for example a Message Object JSON Schema file, ONLY contained the information about how a message can be defined, and not that messages can be defined as both a Reference and a Message Object.

Currently, we defined a Message Object as being:

{
  "oneOf": [
    {
      "$ref": "http://asyncapi.com/definitions/2.3.0/Reference.json"
    },
    {
      ...
    }
  ],
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://asyncapi.com/definitions/2.3.0/message.json"
}

However, I feel like a Message Object should only be defined as is (without reference)

{
  ...,
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://asyncapi.com/definitions/2.3.0/message.json"
}

While the definition of Messages should contain the reference:

{
  "type": "object",
  "additionalProperties": {
    "oneOf": [
      {
        "$ref": "http://asyncapi.com/definitions/2.3.0/Reference.json"
      },
      {
        "$ref": "http://asyncapi.com/definitions/2.3.0/message.json"  
      }
    ]
  },
  "description": "JSON objects describing the messages being consumed and produced by the API.",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://asyncapi.com/definitions/2.3.0/messages.json"
}

This issue defines a list of tasks that need to be performed in this repo to make sure it's ci/cd automation works long term without any issues.

It is up to maintainers to decide if it must be addressed in one or multiple PRs.

Below are 3 different sections describing 3 different important ci/cd changes.

IMPORTANT-START
For GitHub workflows that contain This workflow is centrally managed in https://github.com/asyncapi/.github/ you do not have to perform any work. These workflows were already updated through the update in .github. The only exception is the workflows related to nodejs release. More details in Upgrade Release pipeline - in case of nodejs projects section
IMPORTANT-END

Deprecation of way data is shared between steps

Every single GitHub Action workflow that has echo "::set-output name={name}::{value}" need to be updated to follow echo "{name}={value}" >> $GITHUB_OUTPUT

We do not yet know when set-output will stop working. Previous disable date was 31.05 but now then say community needs more time.

For more details read official article from GitHub

Deprecation of node12

2nd bullet point is still relevant for you even if your projects in not nodejs project

• Every single workflow that uses setup-node action needs an update to follow v3 version of this action, and make sure minimum node 14 is used
• Now this part is more complex. Problem with node12 is that node-based GitHub Actions were using it in majority as a runtime environment. Look for example at this action.yaml file for setup-node action v2. So the job that you have to do is go through all the workflows, and verify every single action that you use, make sure you are using the latest version that is not based on node12. I already did review a lot of actions as part of this PR so maybe you will find some actions there and can copy from me. For example action/checkout needs to be updated to v3.

Node12 end of support in action is probably September 27th.

For more details read official article from GitHub

Upgrade Release pipeline - in case of nodejs projects

ignore this section if your project is not nodejs project

You have 2 options. You can:

A. choose to switch to new release pipeline using instruction from asyncapi/.github#205

B. stay with old release pipeline, and manually update GitHub workflows and actions used in it, you can inspire a lot from this PR asyncapi/.github#226

I definitely recommend going with A

Workflows related to release:

• .github/workflows/if-nodejs-release.yml
• .github/workflows/if-nodejs-version-bump.yml
• .github/workflows/bump.yml

Part of asyncapi/parser-js#481

This change, once ported to next-major branch, will make https://github.com/asyncapi/parser-js/blob/next-major/src/schema-parser/asyncapi-schema-parser.ts#L38-L53 to provide wrong types.

TBH is not an issue with this PR per se. The way we are exporting the schemas is not helping. I think we could introduce the following separation in next-major branch:

declare const _exports: {
    'schemas': {
        // ...
    },
    'schemas-without-$id': {
        // ...
    }
}

Do you think it makes sense? If it does, +1 to merge this and start doing those changes in next-major.

cc @magicmatatjahu @jonaslagoni

Originally posted by @smoya in #298 (comment)

Reason/Context

This is a follow-up issue coming from asyncapi/spec#458.

Description

As per the RFC, we need to add support for messageId at message level. This issue helps tracking progress on it.

Note: since the feature is not considered a breaking change, we could include it either on 2.3.0 or 3.0.0, depending on how "fast" we move on.

cc @WaleedAshraf

This issue is a part of AsyncAPImentorship program #78

Main Objective

As part of the Mentorship program we need to validate the extensions with json schema.
A folder named extensions would be added just as bindings are present.

Description

#280
In brief, An extension enables the description of functionality or protocol related features. Everyone can create their own extensions to give users more freedom on the spec.

We need to have a JSON Schema validation. In fact, to enable validation in the parser, we need JSON Schema for AsyncAPI to contain JSON Schemas of individual extensions.

The final objective is to have a catalog of extensions that users can browse and use. Then, as time goes by, we enhance the catalog according to the demands / needs.

cc: @derberg

Part of asyncapi/spec#734 (comment).

I'm asking Code Owners to create the following branches:

• next-spec
• next-major-spec

Describe the bug

It is possible to define a message such as:

      message:
        oneOf:
          - name: LightMeasured
            payload:
              type: string
          - oneOf: 
            - name: LightMeasured2
              payload:
                type: string

and having the schema valid, this should not be the case.

How to Reproduce

asyncapi: 2.6.0
info:
  title: Streetlights API
  version: 1.0.0
  description: |
    The Smartylighting Streetlights API allows you
    to remotely manage the city lights.
  license:
    name: Apache 2.0
    url: 'https://www.apache.org/licenses/LICENSE-2.0'
servers:
  mosquitto:
    url: 'mqtt://test.mosquitto.org'
    protocol: mqtt
channels:
  light/measured:
    publish:
      summary: >-
        Inform about environmental lighting conditions for a particular
        streetlight.
      operationId: onLightMeasured
      message:
        oneOf:
          - name: LightMeasured
            payload:
              type: string
          - oneOf: 
            - name: LightMeasured2
              payload:
                type: string

Expected behavior

I was expected the validation of said AsyncAPI file to be invalid instead of valid.

Reason/Context

As part of the "MVP integration of extensions catalog with AsyncAPI tools to make extension catalog useful" mentorhsip program, detailed here asyncapi/extensions-catalog#78. We would like to add in this repo a part that concerns the description of extensions. In the same way as the bindings and spec.

Description

In brief, An extension enables the description of functionality or protocol related features. Everyone can create their own extensions to give users more freedom on the spec.

We need to have a JSON Schema validation. In fact, to enable validation in the parser, we need JSON Schema for AsyncAPI to contain JSON Schemas of individual extensions.

The final objective is to have a catalog of extensions that users can browse and use. Then, as time goes by, we enhance the catalog according to the demands / needs.

This package doesn't have the schema for version 1.2.0, and it's causing other packages to not work properly. See asyncapi-archived-repos/docgen#29.

Describe the bug

IDEs, like VSCode, cannot determine the version of the JSON Schema file to use based on the AsyncAPI version in use.

How to Reproduce

• Copy any example from https://github.com/asyncapi/spec/tree/master/examples
• Change the version from 2.4.0 to 2.3.0.
• You will still notice the IDE is using AsyncAPI (2.4.0.json) (as in the screenshot above).

Expected behavior

IDEs should pick up the proper JSON Schema file based on the version selected on the AsyncAPI file.

The solution can be found in SchemaStore/schemastore#2229 (comment)

issue might be with any bindings, not just channel, I did not check

spec says that in channels I can also have $ref

which makes sense as I want to have some reusable stuff in components. channelBindings

I would expect below example to work (studio direct link - btw I love new share button in studio:

asyncapi: '3.0.0'
info:
  title: MySlackBot API
  version: '1.0.0'
  description:  |
    The MySlackBot App manages popular messages in a workspace by monitoring message reaction data from Slack's Event API.
    
servers:
  ws:
    host: wss://wss-primary.slack.com/
    protocol: wss
    description: "Websocket URL generated to communicate with Slack"
channels:
  root:
    address: /
    messages:
      reactionListener: {}
      helloListener: {}
    bindings:
      $ref: "#/components/channelBindings/connectionQuery"
      
operations:
  helloListenerOperation:
    action: receive
    channel:
      $ref: "#/channels/root"
    messages: 
      - $ref: "#/channels/root/messages/helloListener"
  reactionListenerOperation:
    action: receive
    channel: 
      $ref: "#/channels/root"
    messages: 
      - $ref: "#/channels/root/messages/reactionListener"

components:
  channelBindings:
    connectionQuery:
      ws:
        query: {}

but this says is not allowed

bindings:
      $ref: "#/components/channelBindings/connectionQuery"

After so many years, I still do not feel like JSON Schema expert so can you confirm, but I think in here https://github.com/asyncapi/spec-json-schemas/blob/next-major-spec/definitions/3.0.0/channel.json#L65 we should instead have something like

"bindings": {
      "oneOf": [
        {
          "$ref": "http://asyncapi.com/definitions/3.0.0/Reference.json"
        },
        {
          "$ref": "http://asyncapi.com/definitions/3.0.0/channelBindingsObject.json"
        }
      ]

thoughts?

Reason/Context

JSON Schema Draft 7 is the JSON Schema version AsyncAPI is compatible with.
All our schemas are written with such dialect, ergo we specify it through the $schema field.
We also make references to that same schema when referencing through $ref.

As you can notice, we strongly depend on such JSON Schema schema.
I'm suggesting we include it as part of our schemas collection so any tool can directly load all schemas, including the JSON Schema Draft 7 on their Schema registries so they don't need to fetch it externally.

A recent real use case can be found asyncapi/studio#159, where the JSON Schema Draft 7 should be provided to Monaco editor YAML plugin in order to avoid fetching it through a HTTP Request.

The plan will also include one JSON Schema schema file per version we require, meaning if we ever adopt a newer JSON Schema draft, we will include it as well here.

Description

Add a new file into /schemas called json-schema-draft-07.json with the exact content of http://json-schema.org/draft-07/schema.

Reason/Context

Parser-JS requires now Node.js 14 and npm7 or higher.
This means package-lock.json version should be always set to 2.

Description

In order to unify development requirements, I suggest all repositories to stick with that requirements. In order to do that, the following is needed:

• Clarify this requirement under Development section on this repository README file.
• To update package-lock.json to version 2. This is automatically done when running npm install if the npm version used is 7 or higher.

Related:

• asyncapi/.github#177

Imho https://github.com/asyncapi/spec-json-schemas/blob/next-major-spec/definitions/3.0.0/messageObject.json#L73 should be replicated in https://github.com/asyncapi/spec-json-schemas/blob/next-major-spec/definitions/3.0.0/messageTrait.json#L70

cause if somebody will be allowed anything with examples in trait, then trait merging will never work

probably best solution would be to introduce separate reusable MessageExamples.json and reuse it in messageObject.json and messageTrait.json with $ref

More info in asyncapi/studio#146 issue. We should change all hrefs in $schema property to https - atm all have http like https://github.com/asyncapi/spec-json-schemas/blob/master/schemas/2.2.0.json#L3.

Describe the bug

According to the spec, a message in the component section should not be able to be defined with oneOf, but at the moment the following is valid:

components:
  messages:
    myMessage:
      oneOf:
        - name: LightMeasured
          payload:
            type: string

Expected behavior

Expected a validator to mark this as invalid input.

Describe the bug

The schema for v2.0.0 (and all older versions) does not allow to extend the components object with specification extensions. This is inconsistent with the specification which states that the components object can be extended with specification extensions.

How to Reproduce

Validating the following exemplary AsyncAPI document against the v2.0.0 schema with any JSON schema validation library results in an error like Property 'x-extension' has not been defined and the schema does not allow additional properties or similar:

{
    "asyncapi": "2.0.0",
    "info": {"version": "1.0", "title": "Example API"},
    "channels": {},
    "components": {
        "x-extension": "xxx"
    }
}

Expected behavior

Above AsyncAPI document should be validated without errors.

we still expose AsyncAPI 1.0, 1.1 and 1.2 but we do not really support it anymore.

we should remove it and release new major

these old schemas use draft 4 as base. The new ones use draft 7. So in parser we are forced to point to draft 4 as meta schema for ajv. So we do something in the parser that do not make much sense, as parser do not support asyncapi prior 2.0

thoughts?

cc approvers @fmvilas @dalelane

Describe the bug

Since the option esModuleInterop: true is not set to the project, the file index.d.ts cannot be compiled. This happens because the module definition of the file uses an invalid export syntax, when it should use the export= syntax type. This is described better on this documentation: Module.d.ts

Note that using export default in your .d.ts files requires [esModuleInterop: true](https://www.typescriptlang.org/tsconfig#esModuleInterop) to work. If you can’t have esModuleInterop: true in your project, such as when you’re submitting a PR to Definitely Typed, you’ll have to use the export= syntax instead

File path: https://github.com/asyncapi/spec-json-schemas/blob/master/index.d.ts

How to Reproduce

npm run build:prod (tested in local environment only)

Link to GitHub repository with project that has issues:
https://github.com/asyncapi/server-api

Expected behavior

After running the command, it should finish without any build errors.

Describe the bug

Because the examples was applied to v2.6 and not v3, it means that going forward and in v3, examples will no longer be available.

cc @AceTheCreator

Should we rename this repo to schemas or similar? It will not be only for Node.js but for other languages too.

Describe the bug

In b51f0aa#diff-c42eed206b44fe4fa90f1635ff156f9804ae2450b901771b9c4d6db5188d640cR173 we released a property to the server object, to contain $ref instead of using the existing reference definition.

This results in an inconsistency in how references are defined.

Expected behavior

All references should use the same reference definition.

Describe the bug

According to redhat-developer/yaml-language-server#585 and microsoft/vscode-json-languageservice#123 the use of hashes to reference eternal schemas is not supported.
$ref '/definitions/schemaArray' in 'http://asyncapi.com/schema-store/2.4.0.json' can not be resolved.

How to Reproduce

Create a new asyncapi.json or asyncapi.yaml file in vscode with the yaml extention installed.

Expected behavior

The schema should resolve by the language servers used by the extention.

The workflow stale-issues-prs.yml is referencing action actions/stale using references v1.1.0. However this reference is missing the commit af4072615903a8b031f986d25b1ae3bf45ec44d4 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

#124 introduced symetric releases for the package. So basically whenever there is a change in Go package, we will also release JS package in all the different projects that depend on it. Cause a lot of noise with "empty" functionality.

1. Go package should have its own release cycle. Symetric releases are cool but for cases like in react-component where we release web-component and other things at the same time
2. I know some time ago we took JSON Schema files out from spec repo and moved it here to have one project with JSON Schemas and projects for different languages. But I admit, that in this discussion I never took into consideration release process and how strange things will work here. IMHO the best would be to leave JSON Schemas in this repo alone, then JS code should go to js-json-schemas and Go should go to something like go-json-schemas. Once JSON Schema is released with some update, there should be a workflow that pushes updated json schema to JS, Go and other projects and release is triggered there automatically

Related conversation: #118

Describe the bug

I opened this PR #339 fixing this issue for v2, and I noticed it still persists in the upcoming version

More on the issue can be found here #273

cc @derberg @jonaslagoni

Describe the bug

The schema of the MessageObject contains a deprecated property. This property is not included in the MessageObject documentation or the markdown. Shouldn't it be though?

Describe the bug

Similar to #164 we have a problem with parameter defining it's own reference property:

Expected behavior

Parameters should use:

  "additionalProperties": {
    "oneOf": [{"$ref": "#/definitions/parameter"}, {"$ref": "#/definitions/Reference"}]
  },

Context

1. We want to make sure we have healthy community and people respec each other in GitHub. We want to monitor all comments in every repository and analyze sentiments to identify negative ones and get proper notification. Idea is to use GitHub Actions for it, to check sentiments with Google Natural Language API and post negative comments to Slack for review.

2. We manage community files in global .github repo, and we have GitHub Funding config file there too. As a result we need to cleanup all the repos to remove .github/FUNDING.yml

3. Start supporting new GitHub pull request event that allows gives access to GITHUB_TOKEN with write access. Fix welcome contributors workflow is needed.

4. We want to automatically merge Pull Requests that are submitted by Dependanbot. New workflow needs to be added, or if already existins it needs to be modified

Description

1. Add this workflow file called sentiment-analysis.yml to .github/workflows (create it if it doesn't exist yet) directory: https://gist.github.com/derberg/ab362e4b37f542e7e1813e67b7cb11ee
   Proper secrets are already added to GitHub organization so it is as simple as adding above file to workflows dir.
2. Remove .github/FUNDING.yml if it exists
3. If not done already rename pull_request from line 4 to pull_request_target in .github/workflows/welcome-first-time-contrib.yml file
4. Create new file called automerge.yml with the following content: https://gist.github.com/derberg/024814a26959d54f683e7bd68d68f007
   If the repository already has a file called automerge-release-pr-bump.yml than rename it and adjust if statements to check github.actor == 'asyncapi-bot' || github.actor == 'dependabot[bot]' || github.actor == 'dependabot-preview[bot]' instead of github.actor == 'asyncapi-bot'

Describe the bug

As we can see in the Studio:

In the channel's parameters we cannot make references.

How to Reproduce

Open https://studio.asyncapi.com/?url=https://raw.githubusercontent.com/asyncapi/spec/master/examples/streetlights-kafka.yml and convert to the JSON - right corner of the editor -> Convert to JSON and you should see yellow marker under $ref used in any channel's parameter (in YAML format you won't see error due to the asyncapi/studio#509 issue).

Expected behavior

As a user I can make reference to the channel's parameter without "referencing" errors.