Handle lack of port more gracefully?

[jpw]

If port is not specified we get a spawn loop. Not great I guess, but not sure if this is a thing to be fixed.

Maybe we should catch this and halt?

$ node app -p --route-override=$BACKEND_APP
...
internal/net.js:17
    throw new RangeError('"port" argument must be >= 0 and < 65536');
    ^

RangeError: "port" argument must be >= 0 and < 65536
    at assertPort (internal/net.js:17:11)
    at Server.listen (net.js:1383:5)
    ...
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
2016-11-10T12:23:15.638Z - error: 31131 died with error code 1, starting new worker...
...

[andrewmee]

I thought we defaulted to port 80 (for http). Let's have a look at this and see how we're getting into this loop.

[hollsk]

See #103 - we should be accepting port 80 as the default.

[andrewmee]

Oh I've just realised, you're explicitly calling -p for port, but not providing one.

That would probably explain why it's not using the default. I guess we could do a better job of just throwing the error once instead of looping, but an error it would be.

[jpw]

Thinking some more, should we apply 80 if port number is unspecified and warn the user, or exit?

[hollsk]

Just exiting would be unexpected behaviour, IMO. Port numbers are so well-known that I think most people expect applications to have some insight as to their intentions, even when they're not explicitly stated.

Notifying the user that 80 is being defaulted to would be reasonable, though.

[josebolos]

I can't seem to be able to replicate this issue using just Shunter. I'm assuming this is an app using shunter that is failing in this manner?

That said, the behaviour with shunter itself is quite inconsistent at the moment. For example:

1. No port specified:

$ node ./bin/serve.js
Shunter Serve started on http://localhost:5401
^C

2. -p specified but empty:

$ node ./bin/serve.js -p
Shunter Serve started on http://localhost:3000
^C

3. -p 80 specified (fails as expected due to not being root):

$ node ./bin/serve.js -p 80
events.js:182
      throw er; // Unhandled 'error' event
      ^

Error: listen EACCES 0.0.0.0:80

Behaviour 2 is wrong and needs to be corrected. An invalid or incomplete argument string being passed to an app is an error, this is standard behaviour on every UNIX app that I know:

Valid argument string:

$ ls --color=never
HISTORY.md  Makefile   bin       docs  filters  logging       package.json  tests
LICENSE     README.md  coverage  dust  lib      node_modules  public        view

Invalid argument string:

$ ls --color=muffin
ls: invalid argument ‘muffin’ for ‘--color’
Valid arguments are:
  - ‘always’, ‘yes’, ‘force’
  - ‘never’, ‘no’, ‘none’
  - ‘auto’, ‘tty’, ‘if-tty’
Try 'ls --help' for more information.

I'm going to have a go at fixing scenario 2 by making it error out. We can see then how it affects Jon's scenario.