Generator cannot handle referenced types (in separate files)

[oskarcarlstedt]

Describe the bug

It looks like the generator cannot handle types that are referenced in other files. Declaring the type locally in the schemas section works perfectly, but not when declaring the type in a separate file and referencing it.

I like to use the same model definitions in OpenAPI and AsyncAPI implementations. Therefore I want to share some types between these two types of API definitions.

How to Reproduce

Just run the generator using the java-spring template and we gen an error saying this is not an AsynAPI file.

asyncapi: "2.6.0"
info:
title: An asynchronous API
version: 1.0.0
description: |
An API dealing with asynchronous actions on some objects

defaultContentType: application/json
channels:
objects.new:
subscribe:
operationId: pushNewObjectToSubscribers
message:
$ref: "#/components/messages/ObjectMessage"

components:
messages:
ObjectMessage:
payload:
$ref: "types.yaml#/components/schemas/SomeType". <<<--- This is the type that cannot be found

Expected behavior

Find and read the type in the reference file.

[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]

@oskarcarlstedt please format your example asyncapi file so it is easy to copy and paste so we can try replicating the issue. And share types.yaml too 🙏🏼

[michael-ball-ctct]

Hi @derberg
Obviously, not quite the same example, but I'm fairly sure I'm running into the same issue with the following files in the same folder:

# asyncapi.yml
asyncapi: '2.6.0'
info:
  title: Account Service 2
  version: 1.0.0
  description: This service is in charge of processing user signups
channels:
  user/signedup:
    subscribe:
      message:
        $ref: '#/components/messages/UserSignedUp'
components:
  messages:
    UserSignedUp:
      payload:
        type: object
        properties:
          displayName:
            type: string
            description: Name of the user
          email:
            type: string
            format: email
            description: Email of the user
    SignUpFailed:
      payload:
        $ref: ./asyncapi-ref.yml#/components/messages/SignUpFailure

# asyncapi-ref.yml
components:
  messages:
    SignUpFailure:
      payload:
        type: object
        properties:
          displayName:
            type: string
            description: Name of the user
          email:
            type: string
            format: email
            description: Email of the user
          failure_reason:
            type: string
            description: The reason this signup was unsuccessful

Which results in:

Desired result would be that is contains the information contained in the asyncapi-ref.yml for the SignUpFailure message component, rather than just Any.

Hopefully this formatting and screenshot of the result helps to make this issue more clearly understandable - it's a significant thorn in my side. Cheers!

[oskarcarlstedt]

I'm sorry for not being active in this topic. I've been off with other stuff for a while. However, it's exactly the same issue as @michael-ball-ctct explains.

Thanks
/Oskar

[michael-ball-ctct]

@oskarcarlstedt In case you haven't found a workaround yet - I ended up using https://github.com/udamir/api-ref-bundler to bundle the referenced files into the root definition (and reading my .yml definitions using https://www.npmjs.com/package/js-yaml ).

I haven't tested this exact script, as it's a rough minimal repo from my actual codebase, so it may not work perfectly but is hopefully enough to give you the right idea. But this is roughly what I ended up using:

import { load } from "js-yaml";
import { readFileSync } from "fs"; // readFileSync was good enough for my initial purposes, readFile is probably better in the long run
import Generator from "@asyncapi/generator";
import { resolve as pathResolve } from "path";

function resolver(sourcePath) {
    return load(readFileSync(ymlPath).toString());
}

const onErrorHook = (msg) => {
    throw new Error(msg)
}

async function asyncAPIWriter(definitionPath) {
    await bundle(definitionPath, resolver, { hooks: { onError: onErrorHook}}).then(schema => {
        const generator = new Generator(
            "@asyncapi/html-template",
            pathResolve("./my/output/folder/",
            { forceWrite: true } // forcewrite allows us to write into a repo that has a git project in it, use at your own discretion
        );

        generator.generateFromString(JSON.stringify(schema))
            .then(()=> {
                // do your stuff
            })
            .catch((e)=> {
                throw(e);
            });
    });
}

It's worth noting that api-ref-bundler is a fairly unknown project, so you may wish to do your due dilligence in reviewing it before using it. It looked solid enough to me, but you might see something I didn't or be working with a stricter risk profile.

Hope this helps.

[oskarcarlstedt]

Sounds good. Maybe that’s something I can use. Thanks!!!

[derberg]

I think it is related to asyncapi/parser-js#761, which is bad news atm

[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 ❤️

[AnimeshKumar923]

still valid? @derberg
cc: @oskarcarlstedt

[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 ❤️

[derberg]

@oskarcarlstedt to solve this, we need someone to solve asyncapi/parser-js#761

maybe since Spectral is now owned by SmarBear (that acquired Stoplight) something will change there. I added comment to stoplightio/spectral#1054

[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 ❤️