-
-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: new CLI architecture (part 1) #1200
Conversation
4e5dcca
to
fdfb8cf
Compare
ad2a686
to
80c1f37
Compare
Quality Gate passedIssues Measures |
As this PR is quite big, I'll create additional issues for |
regarding this new architecture, where current also, looking at new architecture proposal. Let's imagine that I want to propose that some repos for libraries that are used in CLI and Studio should be merged here. Let's say (not consulted with anyone, just in my head for a while) we decide to merge https://github.com/asyncapi/optimizer/ in, still released as independent package, but source code developed under CLI repo. Would that be another adapter? |
All commands + API share the same The input adapters that we have for now are CLI and API, in the example you provided it feels more like a business logic that needs to be merged and used by the
|
one in the root? |
Yes |
@Amzani ok, than in theory release process should not be affected. Just keep in mind that package.json keeps the project name and version and it should eventually reflect what is published to npm. But yeah, I agree that can be done later, as in the end |
80c1f37
to
885caa0
Compare
@Amzani I suppose we can try to merge this PR as conflicts will keep piling up. |
src/cli/commands/start/index.ts
Outdated
import { Help } from '@oclif/core'; | ||
|
||
export default class Start extends Command { | ||
static description = 'Start asyncapi studio'; | ||
static description = 'Start asyncapi studio, or asyncapi server'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to use the start
command also for running asyncapi servers? In that case, this PR might resolve #1090
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
40d7d9f
to
d916581
Compare
7d1eb3d
to
98999a5
Compare
Quality Gate passedIssues Measures |
As this is a big change I'll merge the changes in different PRs, for now I'm delivering part 1) which includes:
Having API as part of CLI is not yet clear as per my comment here - If the only studio is the API consumer, and api-server package is not used why increase the complexity of CLI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀 @Amzani.
/rtm |
🎉 This PR is included in version 1.18.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
What's your use case @AayushSaini101 |
Resolves asyncapi/server-api#485
Resolves #781
This PR introduces changes discussed in asyncapi/server-api#485 (comment) and #781 (comment)
New features
New architecture/flags extractions
This architecture will enable CODE Maintainers split discussed in #781
API foundations
To test the API
http://localhost:3001/v1/ping is also available
Scope
/generate
API endpoint