[GSoC 2026 ] Improve the performance and efficiency of the CLI

[AayushSaini101]

Overview:

This initiative aims to guide you on a journey from being a contributor to becoming a maintainer of the project. You'll gain insight into the responsibilities of a maintainer, involving tasks beyond mere coding.

Being a maintainer entails:

• Defining potential enhancements as GitHub issues
• Actively triaging incoming requests and bug fixes
• Resolving bugs or providing guidance to others
• Shifting focus from creating code to reviewing it at the pull request level
• Occasionally writing documentation
• Improvement refactors, writing tests - still very important
• And yes, sometimes coding new features
• It's about taking responsibility for the project's future and continuous improvement. It's less about the brilliance of the code you produce. All of the activities described above will be part of the mentorship journey.

Why is this an interesting project?
To secure a job, you need experience. Completing a single project or contributing code for one feature isn't substantial experience. However, becoming a maintainer—now, that's something you can proudly showcase in an interview. I can't guarantee that completing this mentorship will immediately qualify you to become a project maintainer. Your performance, attitude, and motivation will determine that. However, I can promise to support you throughout the journey and provide honest feedback on your strengths and areas needing improvement. Even if you're not yet ready to become a maintainer, I'll outline a plan for your next steps towards achieving that goal. I would highly recommend to read the blog post written by Lukasz Gornicki (@derberg) - https://www.brainfart.dev/blog/maintainership for more details about Maintainership.

Project Description:

The AsyncAPI CLI is a cornerstone of the AsyncAPI ecosystem and is close to feature completeness. However, its performance bottlenecks, test instability, and growing maintenance overhead currently limit both contributor productivity and end-user experience.

This project focuses on optimising command execution, improving test reliability, and enhancing overall usability and debuggability of the CLI. Addressing these issues will significantly reduce friction for developers, improve CI reliability, and ensure the CLI scales effectively as the AsyncAPI ecosystem continues to grow.

The CLI currently has multiple open maintenance and performance-related issues that directly impact daily usage and contributor confidence, making this work both timely and high-impact for the community.

Problem Statement & Scope

Key areas of focus include:

• Profiling and optimising slow CLI commands, with particular emphasis on the generate command, which is one of the most frequently used and performance-critical workflows.
  Reference: Overarching issue for tracking progress #1929
• Improving test stability and reliability by identifying flaky tests, optimising test setup, and reducing dependency-related failures.
• Evaluating and potentially migrating the package manager/runtime (e.g., Bun or pnpm) to reduce installation time, improve dependency resolution, and speed up CI pipelines.
• Reducing long-term maintenance burden by simplifying command execution paths, improving internal abstractions, and strengthening debugging support.
• Package size reduction of the CLI currently, the CLI is very heavy while installing, need to optimise it properly

Expected Outcomes

• By the end of GSoC 2026, the AsyncAPI CLI will:
• Deliver significantly faster command execution, especially for generation workflows.
• Have more reliable and deterministic test suites, reducing CI failures and maintenance effort.
• Offer faster installation and setup times, improving first-time contributor experience.
• Provide better debugging and usability features, making the CLI easier to use, extend, and maintain.
• Enable higher contributor confidence and smoother onboarding for new developers.
• These improvements will directly enhance both end-user developer experience and long-term project sustainability.

Skills Required

• JavaScript / TypeScript
• Node.js ecosystem
• Performance optimisation (profiling, dependency management, runtime analysis)
• Testing frameworks and tooling
• API design and integration

Difficulty Level

High (350 hours)

Mentors: @AayushSaini101 @Shurtu-gal @Souvikns

Resources

• AsyncAPI CLI Repository: https://github.com/asyncapi/cli
• AsyncAPI Generator Performance Discussion: Generator doesn't pull template from private repo generator#538
• Bun: https://bun.sh/
• pnpm: https://pnpm.io/
• Spectral Rules for API Validation: https://docs.stoplight.io/docs/spectral/

[Shurtu-gal]

@AayushSaini101 please include package size reduction through probably optional installs as well please.

[neoandmatrix]

A few improvements that i would also like to suggest.

1. We currently release .deb files of cli for linux. We can try to expand that to other popular linux distributions like Redhat linux based distributions with (.rpm) and with Appimage to even more variety of distros. This would help the users to natively install and use cli without installing any other runtime.

2. A global configuration file for cli where users can set some pre-determined arguments or configuration to be used with cli.

Would like to know your thoughts on this.

@AayushSaini101 @Shurtu-gal @Souvikns

[abhi-03-kh]

Hi @AayushSaini101 @Shurtu-gal @Souvikns ,

I’ve been investigating the Package Size Reduction goal mentioned in the description, and I believe I've identified the root cause of the heavy install.

Current Status

The node_modules size on a fresh install is ~1.6GB.

The Root Cause

It appears that src/domains/models/Studio.ts has a static import of the @asyncapi/studio package. This forces the entire Studio web application to be installed as a production dependency for every CLI user.

Because of this strict dependency, we are pulling in massive transitive dependencies like:

• next
• monaco-editor
• react-icons

This seems unnecessary for users who only use the CLI for CI/CD pipelines (e.g., validation/generation) and never open the Studio.

Proposed Solution

I propose refactoring the CLI to use Dynamic Imports (lazy loading) for the Studio. We can ensure @asyncapi/studio is only fetched/loaded when the user explicitly runs asyncapi start studio. Alternatively, we could decouple it into a separate plugin (@asyncapi/cli-plugin-studio).

I plan to tackle this architectural decoupling as a primary deliverable in my GSoC proposal. Before I finalize the plan, do you have a preference between the Dynamic Import approach vs. the Plugin approach?

[abhi-03-kh]

Update: I went ahead and prototyped the Dynamic Import approach to validate the size reduction theory.

Draft PR #1994 demonstrates ~57% install size reduction (1.6GB → 698MB) while maintaining full functionality. The mechanism uses optionalDependencies + dynamic imports.

@AayushSaini101 @Shurtu-gal — I'm ready to discuss whether this fits into the GSoC scope or should proceed as a standalone optimization.