fix: disclose limitation about parameter schema reference

[jonaslagoni]

Description
If a parameter's schema is defined with a reference in v2, it would completely be removed in v3, because we cant manipulate references correctly yet, see #90

[derberg]

just noticed problem is not only with parameters that have schema as reference

look at https://github.com/asyncapi/spec/blob/master/examples/rpc-client.yml

  '{queue}':
    parameters:
      queue:
        schema:
          type: string
          pattern: '^amq\\.gen\\-.+$'

v3 conversion makes it queue: {}

at the reason is pattern which we do not have in https://github.com/asyncapi/spec/blob/next-major-spec/spec/asyncapi.md#user-content-parameter-object and imho it means we should add it Parameter Object for 3.0.0

[jonaslagoni]

just noticed problem is not only with parameters that have schema as reference

look at https://github.com/asyncapi/spec/blob/master/examples/rpc-client.yml

  '{queue}':
    parameters:
      queue:
        schema:
          type: string
          pattern: '^amq\\.gen\\-.+$'

v3 conversion makes it queue: {}

at the reason is pattern which we do not have in https://github.com/asyncapi/spec/blob/next-major-spec/spec/asyncapi.md#user-content-parameter-object and imho it means we should add it Parameter Object for 3.0.0

Can only convert to what the spec allows 😄

But yea, agree it's probably a good case for a feature request. For 3.0.0, no, 3.1.0 sure.

[jonaslagoni]

@derberg I still think this should be merged as is, as the other issue you raised does not really affect it 🙂

[derberg]

@jonaslagoni yeah, I agree that pattern is not critical for 3.0 as lack of it will not affect adoption. But it is a known regression that we should document in release notes imho, and probably migration guide, to warn folks that use it. Probably can be additional sentence in section where you talk about parameters in these docs?

Anyway I opened an issue in spec repo to make sure other codeowners agree

regarding this PR, I still see no change and afaik even though error is spotted, conversion continues, so user still gets empty parameter. We should be super clear in the console info, that was not successfully converted AND resulted in an empty parameter object that user needs to update manually

and yeah, we need console.error for pattern

[jonaslagoni]

@derberg I altered the converter to warn the user whenever they use properties in the schema that won't be taken over into the new parameter object, not just for pattern.

I don't think we need to explain anything in the docs though, because it is not really a missing feature 🤔 The regression should be pretty apparent with the warning I added and the migration guide on the website and release notes 🤷

[derberg]

but I had a quick look at asyncapi/website#2008 and there is no mention of parameters and migration related to it, or are my 👁️ wrong

[jonaslagoni]

Nope you right, I missed it 😆

[jonaslagoni]

I will add it to the migration guide 👍

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[derberg]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 1.4.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀