Refactoring scratch pad

1. package (Module dependency) diagram for autolabcli application.

2. Choose the ES2015 programming language style and constructs for new code.

3. The view part right now is console.log. This is deeply embedded in the application. We need to consolidate the view part to one location so that multiple views can be supported from the same model-controller setup.

4. We will use either caporal.js or commander.js. Sebastin Santy is looking into making a choice.

5. The user interface libraries - chalk, color, console, figlet, inquirer, cli-table and spinner - are used for user interface. They are deeply embedded in all js files in lib/ directory.

6. What is the preferred way of specifying the module exports? Are we following the preferred way? In lib/help.js, the crux of the work is done on the module.exports line. Is there a better way?

7. Debug messages sent to log manager by Winston logger. Caporal already has winston embedded in it.

8. Lines 36-65 of index.js can be cleaned up using a <string,call-back-fn> map.

9. Configuration file to be maintained separately. Username and password can be part of the configuration file too. Default configuration file to exist for the installation. User defined parameters can override the values of the default configuration file.

10. JS coding style examples. caporal, commander. Use caporal.js for autolabcli. As per Sebastin Santy, the advantages of caporal.js over commander.js are:

    1. Caporal more documented with good documentation.
    2. Is more open with their code quality and coverage.
    3. There are many features in caporal like Typo suggestion and tab support
    4. Caporal was made even with the existence of commander, which gives a hint that commander might have some less features.
    5. Also, after taking a quick look at package.json, I feel that commander is probably coded bottom up whereas caporal is built upon many known-libraries, some of which we are also using.
    6. Supporting the above statement, the caporal structure seems to fit our existing codebase because of the similarities in the libraries.

11. Modular coding structure to be implented during refactoring. The suggested structure is:

     lib/ 
       model/                    ---> contains the code for doing the actual work (programming logic / model). Modules in cli/ import the corresponding model function objects and puts them in action part of caporal.js
         init.js                 ---> initialize local settings including saving username and passwords
         git.js                  ---> wrapper around JS git-client to help autolabcli interact with GitLab
         help.js                 ---> display autolabcli help (not needed once migration to caporal.js is complete) 
         rev.js                  ---> removes local stored settings including saving username and passwords; should be merged into init.js
         submit.js               ---> make a submission request to AutolabJS main server using socket.io library
    
       cli/                      ---> contains the code for doing the user interaction (uses caporal.js)
         init.js                 ---> init, changehost and exit commands
         git.js                  ---> all git related commands
         submit.js               ---> all commands that help interact with main server
       (each of the modules in cli/ export an object with add(program) method that adds all the required commands to the incoming program object and returns the program object.) 
    
     index.js                    ---> imports the required modules from cli/ and invokes them one after another to create all the commands