RFC CLI architecture

[Brent Jackson]

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

A rough outline of dependencies:

cli/
  node_modules/
    meow/
    kit-dev/
    kit-build/
    kit-publish/
    kit-init/
  cli.js
dev/
  node_modules/
    webpack/
  index.js
init/
  node_modules/
    ink/
  App.js

I would also be okay with all the CLI subpackages being included in the main CLI package if that's easier to manage.

[John Otander]

Was doing some pondering on this as well, definitely agree. We only need to pull in Ink for the prompt portions, so this sounds 💯 to me.