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