Coline — JavaScript Command Line Interface

2 min readJan 1, 2019

Coline provides a slim and reusable framework to define command line applications with a top-level interface and several question-answer dialogs. It is written in Node.js and published as open source on Github respository and NPM.

Coline is my first open source project and also my first programming project in a very long time. This post explains the application scenario for which I wanted to create a framework, and sketches the technical approach I took to create the framework.

Mystery Lunch

In a mystery lunch, people are randomly assigned to a group and go out eating together. The features include:

  • Define the name and time of a lunch event
  • Add people to the lunch event
  • Schedule the lunch by randomly putting people into groups

The application should ask me a set of questions with which to create such an event. It should be an application that you start from the terminal. An example dialog is here:

$> What is the name of the event? (Any signs)

$: Test Lunch

$> When is the event going to happen? (Any signs / ‘Back’)

$: 2018–11–27

$> Who is participating? (Any signs, separated by comma / ‘Back’)

$: Sebastian, Karl, Lea, Caro, Hans, Roger

$> Do you want to create this event? (‘Yes’ / ‘Back’)

— TITLE : Test Lunch

— DATE : 2018–11–27

— PEOPLE : Sebastian, Karl, Lea, Caro, Hans, Roger

$: Yes

$> Thank you, the event has been added

Technical Approach

The approach developed over time. By checking existing open source projects like Commander, Inquirer or the Node.js module Readline. I learned about event handling, async functions, and working with stdin and stdout.

The approach evolved to this set of concerns:

  1. Writing to stdout (with a customizable prompt) and reading from stdin
  2. Defining a user interface that is loaded when the application starts to tell the user about the basic commands, and which provides key => command bindings that are invoked when the user presses the key
  3. Defining dialogs that ask questions, validate the input, and allow to move back or exit the dialog

Each concern should be implemented as a separate component. An application would initialize the prompt, write a message and the user-interface, and then wait for user input to be processed. With this sketch, development could start.

In the next post, I will continue with the design choices and reflect how the separation of concerns evolved