Add "webgme dockerize" command to generate

[pmeijer]

> webgme dockerize --help

  Usage: webgme-dockerize [options]

  Options:

    -h, --help          output usage information
    -p, --production    If set will include templates for a proxy and authentication
    -f, --force-update  If set will overwrite any existing files

This PR also fixes #251 and #250

[brollb]

If you inherit from the ComponentManager (like here) then you can just use the _preprocess fn to wrap it and won't need to rewrite the preprocessing fn-ality. This basically ensures that functions that need to run within an existing webgme app do.

[pmeijer]

I didn't think this command fit within Components so I decided to keep the implementation separate.

[brollb]

That makes sense but I am still torn bc I don't like having two implementations for the same thing...

What if you just "inherited" that method? Something like:

DockerizeManager.prototype._preprocess = ComponentManager.prototype._preprocess;

In the future, we could more _preprocess to be a utility rather than a method defined by the Component base class.

[pmeijer]

I did look into that option. However _preprocess does more than just navigate to the root-dir. It process webgme-setup.json.
I could, however, extract a util function changeDirToRoot (_go_to_root_dir no idea why I made this into snake_case btw).

[brollb]

Would you mind moving the fix for #250 and #251 to their own PR's? It will make it easier to squash them into one when I accept it. If not, it's not that big of a deal - I just like to have a PR address only a single issue to make it easier to review and so I can squash all the commits into a single commit fixing the given issue (github's PR will still preserve the individual commits despite the squash).

Otherwise, it looks pretty good! I might give it one more look over and play with it some myself but the code looks pretty good!

[pmeijer]

Is it fine if I do that next time? They were things that came up while I was working on the dockerize command and to avoid the overhead of switching branches I just put them in the same branch. You are right though - that it's better to keep them separate.
Btw Brian, do you still want PRs from us? Or do you prefer us managing the cli from now on?
Appreciate you taking the time to check this one out!

[brollb]

Yeah, no problem.

I am happy to still review PRs and stuff. However, if you need something faster (and I haven't reviewed it quick enough) don't feel like you have to wait for me. In other words, I would be happy to continue to review PRs but I don't want to get in the way of any urgent fixes/slow development (esp. since my time is a little more divided now).

[pmeijer]

Extracted changeToRootDir and fixed failing test.