prules -s -t -w [--cheats]
source - path to source in a local folder target - URL to target database (includes target env) world-type - name of rules-type document --cheats - allow cheats
CLI context is ./bin/prules
Logic of all context switches and their defaults is implemented at ./lib/params.js
The module logic is ./lib/rules-updater.js
There is a test fixture on ./test/rules_0/
implemented at ./lib/params.js
3 levels of cascading defaults:
1 - CLI parameter - switches are described with 'optimist'. 2 - prules.config.js - options that are commonly used - save time in providing them every time 3 - defaults - some of the switches have hardcoded defaults
(*) names are not the same. CLI Switches have short names, but they support full names too. prules.config uses shorter names of it's own
implemented at ./lib/rules-updater.js
Waterfall with these stages: 1 - getWorldType - gets World Type document from target DB 2 - setVersion - checks version 3 - setParts - update parts on the document 4 - updateWorldType - puts the updated document back to the target DB
important section is the strategy pattern of setPart.
Since in JS functions are first-class objects - the function itself is the dictionary of strategies.
setParts uses a forEachLimit( .., 1 , ...) - for two reasons:
1 - resolving dependency in chdir in async way will make things a little complicated 2 - the output is clearer this way
it is OK to slow down this simple CLI tool...