Add convert command

[magicmatatjahu]

Our comverter-js has builded custom CLI, but we should move it to the main CLI.

AC:

• add new convert command to the CLI
• add tests for new command
• update docs (Readme.md) with new command
• add --help flag
• to discuss: should we remove --id flag from https://github.com/asyncapi/converter-js CLi? It's only needed between 1.X.X -> 2.X.X.

Usage (my proposition):

asyncapi convert --file {FILE} --to 2.1.0 // convert to the 2.1.0 version
asyncapi convert --file {FILE} --to latest // convert to the latest version of spec
asyncapi convert --file {FILE} // convert to the latest version of spec (omit the `--to` flag)
asyncapi convert --file {FILE} --output {OUTPUT_FILE} // convert and save in the `output`

Maybe we should treat --to as standalone argument?

asyncapi convert --file {FILE} 2.1.0 // convert to the 2.1.0 version

I have also problem with --output flag, because I don't know if we should follow with custom CLI for converter:

Any suggestions?

Also we should consider saving the converted spec to the existing context, it means that user will operate on some context and action like:

asyncapi convert --context {CONTEXT} --to 2.1.0

will save the output to the {CONTEXT}.

Some my questions about the future of the command:

• should we only focus on converting the AsyncAPI, or maybe extend it with converting OpenAPI to the AsyncAPI? and another specs 😏
• should we also add option to convert the RAML, AVRO etc formats to our Schema Object format - similar to our custom parsers for formats, but as standalone command in our CLI?

@derberg @Souvikns What do you think?

[Souvikns]

Maybe we have a --output flag that takes a path as an input. Converts the old version to the new version and outputs in that path, and if the --output flag is missing we can just update the original file.

[derberg]

Our comverter-js has builded custom CLI, but we should move it to the main CLI.

definitely, same with generator. This is the ultimate goal of this CLI. One CLI to rule them all 😄

I would definitely like CLI to be friendly and interactive, and when you do asyncapi convert, you get an interactive response from the CLI with list of versions that you can convert too, so you select the version that you want manually. And of course you can skip this interactiveness with a flag like --targetVersion or -t.

the future of the command
my opinion is that we should not put = between asyncapi convert and the JavaScript Converter that we have. Meaning: that now asyncapi convert will invoke the list of available target versions, but simply because in code we will by default support AsyncAPI now, but in future this should be definitely extendable, so we can add other formats, why not 🤷🏼

--output
imho we should do --output as it will be universal for other commands, not >. And if you do not provide --output or -o then we print the result in the terminal

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[peter-rr]

Hi all! 👋 @magicmatatjahu @Souvikns @derberg
I've been having a look and investigating a bit on this issue and I'd like to start working on it as a starting point to contribute to the CLI repo. If no objections from your side, please let me work on it and I'll get back to you with a proposal as soon as I have some working code 💪 Cheers!

[derberg]

@peter-rr go ahead mate!

[magicmatatjahu]

Solution that we should consider for that issue asyncapi/community#249 It's only an idea so please treat it as suggestion, not final approach. Feel free to comment :)

[fmvilas]

I think this issue can be closed as it was implemented by @peter-rr in #188. @Souvikns @magicmatatjahu can you close it? I can do it but I should not 😄

[magicmatatjahu]

Yeah, it's implemented. Thanks!