Synopsis

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

Techincal Info

Project structure

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/

Parameters and Context switches

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

The module logic

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