Export flags to specify which spec is currently supported by bundler

[Souvikns]

Reason/Context

To facilitate seamless integration with other tools that implement bundler, we can enhance compatibility by exporting a designated flag or configuration option. This will effectively communicate the supported spec version, enabling smoother interactions between systems.

We can use the Problem library to define an error code that could be reused in other tools as well. Any tool implementing bundler can check if the spec bundler being used on, is supported or not and throw appropriate warnings and errors.

[Souvikns]

After researching, https://github.com/asyncapi/problem cannot be used how we thought it could be. So problem library does not store the error codes or anything it provides an interface to define errors. So in our case, we have two options

• Define errors in the libraries, so libraries have a soft check for spec version and throw errors accordingly.
• Define all the errors in CLI and export some flags, but this means this features will only work on CLI, not on other tools that are utilizing the libraries

In my opinion, it is better to update the libraries with soft checks so that they are failproof, which helps people that are using just the library. If the bundler does not support v3 bundler should throw that error.

cc. @derberg

[derberg]

yes, problem just gives a common interface. Every library should use it eventually. So bundler is basically a place where we use it as proof of concept, try how later in CLI we can rely on the error to show proper details to users. Then others should follow. But of course we need to take into account that some might not follow, and we need a kind of solution in CLI that will translate custom errors into the ones based on problem.

I'm just thinking what is the advantage of ☝🏼 comparing to a static info that one could provide in package.json

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