-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[RFC] [WIP] feat(cli-core): add a new package for cli in TypeScript #5062
Conversation
4c6de2e
to
2469b6b
Compare
Assigning CLI owners to review this PR:
|
We have experienced a ton of issues with Yeoman and would like to move away from it. The issue #844 is keeping track of the problems. How is this proposal going to affect the process of getting rid of Yeoman? If we are going to introduce a new architecture for our CLI, can we please design it to be independent and decoupled from Yeoman please? |
Thank you @raymondfeng for starting this effort, I agree our CLI codebase is a bit outdated and it's well past time to modernize it. Please work with @dhmlau to plan the time needed by the team to discuss, asses and review your proposals - both the high-level design/architecture and low-level implementation details. At the moment, the PR is adding more 9.3K lines, that's a lot of code to review! I think it's important to find a way how to split this work into smaller chunks that are easier to review and can be landed faster. This will reduce merge conflicts with other ongoing work in CLI and make it easier to resolve those conflicts that cannot be avoided. I am proposing to start with a spike, where you build a prototype (a proof of concept) of the target design. Then we can identify small incremental steps for migrating our current CLI version to the new style, preferably one CLI command at a time. There is one problem I see in the current design that would be great to consider while redesigning our CLI. Consider the following story: As a LoopBack user, I created a LB4 project back in 2019. Artifact templates used by the CLI have evolved since then, but I didn't have time to upgrade my project yet. To keep thing simple for me, I am keeping my globally installed Now I am starting a new LB4 project. I would like to use the latest conventions to avoid introducing tech debt. To do that, I need to upgrade my global Ideally, I'd like the CLI tool to understand what version of conventions/templates my project is using and honor that when creating new artifacts. (end of story) This has been on my mind for some time, I am thinking about the following solution:
I am expecting such design to play very well with I don't have strong opinions on where to draw the line between the parts that should be inside the global CLI and parts that will be installed inside the project. One option is to move all generators to project dev-dependencies and keep only The transition from keeping all logic in the globally installed tool to moving it to a project dev-dependency is not unique to us, popular tools like Most recently, I am seeing projects to use even different setup where no global deps are needed.
|
packages/cli-core/README.md
Outdated
@@ -0,0 +1,3 @@ | |||
# @loopback/cli-core |
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.
We should allow different CLI commands to be packaged in their own modules and contribute to the core as a component.
We already have 26 entries under /packages
directory, I feel that's already too much.
@loopback/cli
has 18 commands (generators) so far. If we put all per-command packages to packages/
, we will end up with 44+ entries 😱
Let's create a dedicated top-level directory for all new CLI packages please. I am proposing to use the directory name cli
, e.g. /cli/cli-core
, /cli/model
, /cli/repository
, etc.
@bajtos Thank you for the great feedback. I agree with what you have said. To clarify, my initial intention is to spend minimal efforts to convert the JS code base to TypeScript and start to embrace our DI. This help us establish an easy-to-refactor baseline. For broader vision to fully renovate the CLI, a spike will be desired. I'll try to come up a high level markdown document to capture objectives, requirements, and ideas to explore, such as: High-level requirements:
Possible Candidates |
This pull request has been marked stale because it has not seen activity within two months. It will be closed within 14 days of being stale unless there is new activity. |
This pull request has been closed due to continued inactivity. If you are interested in finishing the proposed changes, then feel free to re-open this pull request or open a new one. |
This PoC starts to build our CLI commands as TypeScript classes and use
@loopback/core
for dependency injection and extensibility.We should allow different CLI commands to be packaged in their own modules and contribute to the core as a component.
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated👉 Check out how to submit a PR 👈