Deprecation of AsyncAPI Generator CLI - removing ag, not the library

[derberg]

tl;dr

• we have AsyncAPI CLI and asyncapi generate fromTemplate
• all missing features are added to AsyncAPI CLI, just docs need update
• we no longer invest dev time in ag

So what I'm suggesting is basically:

• remove ag, so cli.js and watch related code
• create an issue in every template repository for people to followup and remove any instruction about ag

What I do not know:

• what is the best way to do it.... like it is not a standalone package that we can mark as deprecated in npm as @asyncapi/generator is basically both now, library and cli
• maybe we should join it with my proposed rename How about changing the name of generator and how we call templates #580 so we deprecate @asyncapi/generator on npm and publish the library alone as @asyncapi/generator-core. This might be the best for all the users that use AsyncAPI Generator CLI in CI/CD pipelines. My experience tells me that many people, when use CLIs in CI/CD, do not care much about versioning and install latest. So for example if we remove cli and release it as 2.0, still under @asyncapi/generator then many CI/CD pipelines around the world will explode 😄 which is not nice 😄

[fmvilas]

What about leaving the ag CLI but it always returns an error code and prints a message saying it's deprecated and you should use AsyncAPI CLI? Then in some time from now we just completely remove it.

[derberg]

@fmvilas the problem is that we will break many pipelines, this is why even releasing major will be harmful.

My experience tells me that many people, when use CLIs in CI/CD, do not care much about versioning and install latest. So for example if we remove cli and release it as 2.0, still under @asyncapi/generator then many CI/CD pipelines around the world will explode 😄 which is not nice 😄

Of course we can always say that it is not our fault that people use the tool wrong, but that ain't cool. If we know we might cause issues, we should try to avoid it, thus I think the best would be to simply release @asyncapi/generator-core and deprecate entire @asyncapi/generator.

[smoya]

What about importing the CLI in this generator, and call the generate logic through it? We could show a warning message saying this package is deprecated and keep the generator alive for a while. CLI dependency will be updated automatically (by the bot), meaning feature parity.
We could keep it alive until a new major release of the CLI happens if that works.

[derberg]

@smoya keep in mind that CLI goal is to work just as a CLI and not be used as library.

and call the generate logic through it

this means exec the binary

[smoya]

@smoya keep in mind that CLI goal is to work just as a CLI and not be used as library.

But why adding such a constraint? Is there any strong reason of limiting that? Isn't possible to extract that logic into a proper service that can be called from code? I see only benefits, but for sure there is a reason for not allowing it that I'm missing.

[smoya]

In the very worst case, https://oclif.io/docs/running_programmatically

[fmvilas]

I think the best would be to simply release @asyncapi/generator-core and deprecate entire @asyncapi/generator.

Yeah, I vote for this too then.

[smoya]

I think the best would be to simply release @asyncapi/generator-core and deprecate entire @asyncapi/generator.

Yeah, I vote for this too then.

So just for my understanding, will then that library be used in CLI?

[derberg]

But why adding such a constraint? Is there any strong reason of limiting that? Isn't possible to extract that logic into a proper service that can be called from code? I see only benefits, but for sure there is a reason for not allowing it that I'm missing.

if there will be a strong use case that will be worth the effort, sure, why not. But definitely not worth doing with only assumption it makes sense.

So just for my understanding, will then that library be used in CLI?

yes, it will, it has to. We would just change name from @asyncapi/generator to @asyncapi/generator-core and the new version would not contain the CLI

[smoya]

yes, it will, it has to. We would just change name from @asyncapi/generator to @asyncapi/generator-core and the new version would not contain the CLI

Makes totally sense then. I like the approach 🙌

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

[anandsunderraman]

@derberg What is the process to migrate a generator template from ag to cli ?

[derberg]

@anandsunderraman non. Should work out of the box. You just need to update commands examples in readme, to follow asyncapi generate fromTemplate

[lmgyuan]

Does this issue still need help? Based on my understanding of it, it looks like there might still be work needed to update the readme and documentation to reflect the changes and guide users on how to transition from ag to the AsyncAPI CLI. Is my understanding correct? If so, I am happy to help! : )

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