Refactoring scratch pad

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

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

3. We will use caporal.js. Sebastin Santy is looking into making a choice. 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.

4. Debug messages sent to log manager by Winston logger. Caporal already has winston embedded in it. Make use of it.

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

6. 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.

7. JS coding style examples. caporal, commander. Use caporal.js for autolabcli.

8. 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
   
    test/
      test.js                   ---> functional tests on index.js
      data/                     ---> data / files required for running the tests
      lib/ 
        model/                  ---> directory for tests on lib/model
          init.js
          git.js
          help.js
          rev.js
          submit.js
   
        cli/                      ---> directory for tests on lib/cli
          init.js
          git.js
          submit.js
   

   (Ref: inspiration for this modularity is a similar code structuring used by vorpal.js as explained in this stackoverflow answer)

   The test directories mirror the code structure in the spirit of TDD.

References

1. mastering cli apps
2. Mocking stdin and stdout in node