Replace optimist with nconf and look for .httpserverrc settings file

[timothykang]

I thought JSHint's method of searching up the directory tree would work nicely, as it would allow projects to share settings while also allowing overrides.

Related to #67, closes #24.

[indexzero]

Cool idea! Let me review this weekend.

[indexzero]

Some people use this as a library. We should really be doing:

var nconf = require('nconf');

var config = new nconf.Provider()
  .argv({
    d: { boolean: true, default: true },
    i: { boolean: true, default: true },
    cors: { boolean: true }
  });

[indexzero]

+1 if you can rebase of master

[timothykang]

Rebased and addressed comments. In the process I undid a small change I made to how the boolean showDir and autoIndex options were being parsed that would've broken backward compatibility.

[indexzero]

Will take a look at this over the weekend or next week.

[BigBlueHat]

This is an oldie, but a goodie. I'd like to revisit this again soon, so we can get off the abandoned optimist packaged and on to something more current--nconf seems fine by me.

[timothykang]

An oldie indeed. Rebased onto current master, in light of the renewed interest.

[thornjad]

@timothykang I worked on replacing optimist with minimist in #464, which I still believe is a step in the right direction, but I have to say I like this nconf approach better!

Would you mind taking a look at the merge confict in bin/http-server? Could you also look into specifying the current version of nconf, and make sure it doesn't break anything?

Thank you!

[timothykang]

@thornjad Done!

[thornjad]

@timothykang I'm sorry to ask once again, but my v0.12 merge train has created some more merge conflicts, and has also added some non-nconf settings which need to be converted. Could you take a look?

This PR is next in my merge train queue so master will stop being moving target, I promise!

Also, go ahead and add yourself to the contributor list in package.json, this is definitely a great contribution! (you don't have to if you don't want to).

[thornjad]

Can we use aliases here so that we can avoid the pattern of, for example, config.get('p') || config.get('port')? Instead, it would be nice to have

.argv({
  port: {
    alias: 'p'
  }, ...

And then just use config.get('port').

Note that I think we should use the long form config values as the keys and the short versions as aliases (#464 (comment))

[thornjad]

I think we can use parseValues: true in .argv above rather than need to coerce here. Correct me if I'm wrong on that, I haven't used nconf before.

[timothykang]

@thornjad Rebased. I added value parsing for numbers and where it made sense, but I left the keys as the short forms since not every option had a long form (they could be easily added in a follow-on PR).

[karlhorky]

I guess this can probably be closed, now that #622 was merged instead (switch optimist to minimist)