I think the hostname arg should remain as h (lowercase) for backwards compatibility. That's the way it was before args got introduced:

The problem is that the option opens the help by default: #185. This issue has been opened before args was introduced. The problem already existed we therefore need to rename it to -H.

Besides of that, people shouldn't deploy straight from the master branch (but rather deploy the tree of the latest release). I will adjust the PR for that.

It looks like there's no way to get the tree for the latest tag automatically. That means we would have to adjust the version tag within README.md each time a new version gets released. And since that's not sustainable, I guess we'll have to keep deploying master.

I agree that there should be different flags used for help and hostname, just wanna point out that help wasn't getting open by default previously when passing -h.

-h would always be interpreted as hostname, see this comparison of the commit just before the refactor and the commit just after:

Old version (4ea80c4)

$ bin/slackin -h
error: option `-h, --hostname <hostname>' argument missing

$ bin/slackin -h "0.0.0.0" -p 8888 [subdomain] [api_key] 
Thu Jun 23 2016 19:41:15 GMT 1000 (AEST) – fetching
Thu Jun 23 2016 19:41:15 GMT 1000 (AEST) – listening on 0.0.0.0:8888
Thu Jun 23 2016 19:41:16 GMT 1000 (AEST) – ready

New version (1512684)

$ bin/slackin -h
bin/slackin -h

  Usage: slackin [options] [command] <team-id> <api-token>

  Commands:

    help  Display help

  Options:

    -c, --channels          One or more comma-separated channel names to allow single-channel guests [$SLACK_CHANNELS]
    -C, --coc               Full URL to a CoC that needs to be agreed to
    -S, --css               Full URL to a custom CSS file to use on the main page
    -h, --help              Output usage information
    -h, --hostname [value]  Hostname to listen on [$HOSTNAME or 0.0.0.0]
    -i, --interval <n>      How frequently (ms) to poll Slack [$SLACK_INTERVAL or 5000]
    -P, --path [value]      Path to serve slackin under
    -p, --port <n>          Port to listen on [$PORT or 3000]
    -s, --silent            Do not print out warns or errors
    -v, --version           Output the version number



$ bin/slackin -h "0.0.0.0" -p 8888 [subdomain] [api_key]

  Usage: slackin [options] [command] <team-id> <api-token>

  Commands:

    help  Display help

  Options:

    -c, --channels          One or more comma-separated channel names to allow single-channel guests [$SLACK_CHANNELS]
    -C, --coc               Full URL to a CoC that needs to be agreed to
    -S, --css               Full URL to a custom CSS file to use on the main page
    -h, --help              Output usage information
    -h, --hostname [value]  Hostname to listen on [$HOSTNAME or 0.0.0.0]
    -i, --interval <n>      How frequently (ms) to poll Slack [$SLACK_INTERVAL or 5000]
    -P, --path [value]      Path to serve slackin under
    -p, --port <n>          Port to listen on [$PORT or 3000]
    -s, --silent            Do not print out warns or errors
    -v, --version           Output the version number

I'm worried that changing -h to -H for hostname will break previously working deployments in favour of clearer CLI options - though that might be a tradeoff @rauchg is happy with.

@alexpls One thing I could do on my side is add the ability to overwrite -h within the "args" package. What do you think about that? I feel like it's a good thing on one hand, but on the other, it confuses people because most CLIs are using -h for the usage information.

I think the label of the flags just comes down to personal taste in the end. My suggestion would be to do something similar to what MySQL and Redis do, where -h is the hostname flag and -? is the help flag.

That would have the benefit of keeping -h backwards compatible, and since the help page is shown when incomplete arguments are passed to the slackin command, anyone who would type in slackin -h should still get shown the help page.

Implemented it exactly like you said! Works fine now. Please note that I had to fix the path to the build output (like you did it in your PR) to be able to test it. Because I've also added babel-register, I think you can close #204, if you want.

I'll make sure to mention you in the description section of the PR!