You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the Kit CLI, I think there are two predominant modes for usage: commands that are configured once (via flags or a package.json field) and commands that require different options on each run (via prompts).
The first mode should do what the user wants quickly and without any input required.
The following commands would fall under this category:
dev server
build
publish
The second mode requires some user input that varies on each run.
The init command would fall under this category.
I think meow is a great library to use for the first mode
I think Ink is great for the prompt-based second mode
I feel like Ink will add overhead for the non-prompt-based CLI modules
Package Architecture
I'd propose splitting up packages and dependencies in the following way:
The core CLI package depends on subpackages for all the commands (init, dev, build, publish, etc).
The core uses meow to parse commands and arguments and to display help/usage
Each command has its own package that can be ran as a node module
The dev package, for example, would not include a cli binary and not depend on meow
The core package would not depend on Ink
The init package would export an Ink app where we pass flags as props, and not depend on meow
With the Kit CLI, I think there are two predominant modes for usage: commands that are configured once (via flags or a package.json field) and commands that require different options on each run (via prompts).
The first mode should do what the user wants quickly and without any input required.
The following commands would fall under this category:
The second mode requires some user input that varies on each run.
The
init
command would fall under this category.Package Architecture
I'd propose splitting up packages and dependencies in the following way:
A rough outline of dependencies:
I would also be okay with all the CLI subpackages being included in the main CLI package if that's easier to manage.
The text was updated successfully, but these errors were encountered: