-
Notifications
You must be signed in to change notification settings - Fork 10
Refactoring scratch pad
-
package (Module dependency) diagram for autolabcli application.
-
Choose the ES2016 programming language style and constructs for new code.
-
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:
- Caporal more documented with good documentation.
- Is more open with their code quality and coverage.
- There are many features in caporal like Typo suggestion and tab support
- Caporal was made even with the existence of commander, which gives a hint that commander might have some less features.
- 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.
- Supporting the above statement, the caporal structure seems to fit our existing codebase because of the similarities in the libraries.
-
Debug messages sent to log manager by Winston logger. Caporal already has winston embedded in it. Make use of it.
-
Lines 36-65 of index.js can be cleaned up using a <string,call-back-fn> map.
-
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.
-
JS coding style examples. caporal, commander. Use caporal.js for autolabcli.
-
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.
-
Filter sensitive output from stdout and stderr of console.
-
Give helpful warnings about executing autolabcli from improperly configured directory. Give a suggestion with information about initialised directory and the current directory.
-
Exception handling for all commands.
-
autolab submitcommand does not work properly under expected error conditions. see issue #27. -
autolab initdoes not login properly when the password contains special characters. see issue #32.
- Autolabcli v1.0.0 Docs
- Submission Workflow
- Architecture
- Refactoring Advice
- Feature Development
- Autolabcli Tests
- Events Doc
- Sequence Diagrams
- Testing in Javascript
- Libraries
- Debug Techniques
- Arrow Functions
- Autolabcli v0.1.1 Docs
- References