Open derberg opened 1 year ago
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.
@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
.
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.
@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 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.
In the very worst case, https://oclif.io/docs/running_programmatically
I think the best would be to simply release @asyncapi/generator-core and deprecate entire @asyncapi/generator.
Yeah, I vote for this too then.
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?
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
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 π
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
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 :heart:
@derberg What is the process to migrate a generator template from ag
to cli
?
@anandsunderraman non. Should work out of the box. You just need to update commands examples in readme, to follow asyncapi generate fromTemplate
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! : )
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
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 :heart:
tl;dr
asyncapi generate fromTemplate
ag
So what I'm suggesting is basically:
ag
, socli.js
and watch related codeag
What I do not know:
npm
as@asyncapi/generator
is basically both now, library and cli@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 as2.0
, still under@asyncapi/generator
then many CI/CD pipelines around the world will explode π which is not nice π