Support for multiple versions of generator #1388
Assignees
Labels
Comments
When you say |
|
I mean, that in theory people in production should never install CLI as Same with templates, in production, in pipelines they should run generation with templates not pointing like here, to latest: The problem is - can we assume people do it properly, can we "expect" them do it like this - and have it as defined assumption - so they always manually decide to use new version? the problem with this assumption is that it is not the best DX 🤔 So probably philosophy here should be to always assume people not always read docs, and we should somehow proactively protect them. From my perspective, always better to enable support for new generator version (or optimizer or anything else) and set the older one to deprecate with some period to have it enabled, and then removed 🤔 really hard to decide |
no other option really. We can educate through docs: https://www.asyncapi.com/docs/tools/generator/versioning but this is in my opinion just to make our lives easier, not users |
Sure! Currently we are collecting the template used, and also the CLI version if specified by the user, according to the documentation. I guess we could collect the template version as well if needed 🤔 cli/src/commands/generate/fromTemplate.ts Line 142 in f9a6303 So the different use cases are:
|
|
We can leverage also the efforts @Shurtu-gal is making to improve DX CLI, for instance if we want to force users to explicitly mention versions we can show a documentation link that shows the versions map between generator and templates. |
|
ok, so we look at a solution to support different version of generator in the CLI, right? |
|
Yes @derberg I think it's the most DX friendly option. |
|
are you, maintainers, will work on it or you have no capacity and rather expect contribution? |
|
I think @peter-rr or @AayushSaini101 will be interested in picking it up with some support. |
|
We can submit this as a bounty issue for Q3-2024 |
|
ok, but then we're talking about July. So until July nobody will be able to use new AsyncAPI Generator |
@Amzani Should we add then this issue to the current DX Working Group's cycle? |
|
@peter-rr done |
|
Scope update:
Working on the implementation now. |
This was referenced Jun 20, 2024
Closed
2 tasks
|
@Souvikns |
|
After some research looks like one way of solving this is reading the cli/src/commands/generate/fromTemplate.ts Line 264 in e8dc610 Generator expects a name of the template as a string. So we have two ways to solve this in CLI or generator.
|
|
not doable in generator, thing is that generator recently reached v2 just because of dropping support for some node versions - not really possible to handle such stuff in a different way. and yeah, pre-downloading of packages also seem like an overhead :( downloading will not take place twice though, as arborist package that we use will figure package is already available locally - still this is complex solution - installation is not trivial, there are private packages and other concepts out there that we had to implement in generator, so replicating it in CLI really do not sound like good approach. so maybe in the end we need something in the generator? 🤔 or we just do it "manual" that it is a user of CLI that decides which generator version to use 🤔 |
|
Alright, for now we can have a flag where the user can specify which version of the generator to use, not the best solution but lets the user atleast succesfully generate from all templates. |
This was referenced Sep 6, 2024
|
@derberg I have added the code, do you know about any template that is using generator 2.0.0 or above, I am asking because I will be testing this. |
Bounty Issue's service commentText labels: @asyncapi/bounty_team The Bounty Program is not a Mentorship Program. The accepted level of Bounty Program Participants is Middle/Senior.Regular contributors should explain in meaningful words how they are going to approach the resolution process when expressing a desire to work on this Bounty Issue. |
|
I am working on this @aeworxet, i would love to be assigned to it. |
|
@Souvikns is an AsyncAPI Maintainer specified in https://raw.githubusercontent.com/asyncapi/community/master/MAINTAINERS.yaml, so they fall under the first category in the prioritization list. |
Bounty Issue's Timeline
Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.Keep in mind the responsibility for violations of the Timeline. |
|
With the merge of #1513 CLI is now able to support both versions of generator ie, <2.0.0 and >2.0.0. asyncapi generate fromTemplate ./test/fixtures/specification.yml @asyncapi/newtemplate -o ./check --force-write --use-new-generator
With this, the bounty issue is completed. |
Bounty Issue Is Completed 🎉@Souvikns, please go to the AsyncAPI page on Open Collective and submit an invoice for |
|
closing this issue, as it is done. |
|
I'm afraid there might be issues with implementation in #1513 as it assumes kinda that v2 is the last major generator version.
also look at this strange behavior with logs, when I use the my test command: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So generator reach out v2 dropping support for some node versions: https://github.com/asyncapi/generator/releases/tag/v2.0.0
Normally according to #573 we should bump generator in cli and release new major of CLI. Basically generator drops support for node prior v18 and cli still supports older versions
but this is not a problem
problem is the generator functionality that we have, to prevent templates from failing with new generator version that may have breaking changes, we have such setting: https://github.com/asyncapi/java-template/blob/master/package.json#L102
so if we bump v2 generator in CLI, all the users of templates, will be blocked until templates developers will update config to support v2. Makes sense
so yeah:
Scope
The text was updated successfully, but these errors were encountered: