CI: https://ci.nodejs.org/job/node-test-pull-request/856/

The test sequential/test-net-server-address.js failed, because of the first functional difference mentioned above.
-1 is not a valid port; but before, it was simply changed to false in toNumber, which means a random port.
With this PR however, an error is thrown.

The solution is either to change the failing test, or reintroduce the inconsistency.
What do you think?

I made some updates, the CI should pass now.
I had to change a test, which means this PR is a breaking change (but only in edge cases).

This change would remove a test introduced in 57c56558. /cc @indutny @raymondfeng

Even if the change should happen (about which I have no opinion, at least right now), the test should probably be modified so that it checks the new expected behavior rather than deleting it.

But then I think it should be moved to parallel/test-net-listen-port-option.js.

The problem is this: listen(port) treated illegal ports differently than listen({port: port}), connect(port) and connect({port: port}). This PR makes listen(port) behave like the others, but that is a breaking change.
More precisely, fractions (80.5) were truncated to integers, and invalid ports converted to 0 meaning random port. These cases now would throw errors.

I don't believe this is a big deal. I don't think anybody uses fractions in the port, and I guess that most people don't want to listen on a random port. And if they do, they will probably omit the port or use 0 as the docs say. But if they use something else, it should be easy to fix, as you get a clear error message and can simply follow the stack trace.
However, there was a test that used a port of -1.

What do you think?

The isLegalPort() function that you wish to change appears to have been authored by @bnoordhuis in 480b48244 in order to deal with an API inconsistency. Since that also is the motivation for your proposed change, perhaps he can offer an opinion as to the risk and value of the modifications here.

Marking as semver-major because of the functional changes. It's possible we can downgrade this to semver-minor tho.

rebased

@jscissr ... thank you :-) I'll queue this up for a review shortly. Sorry that it's taken so long :-/

Thanks @jasnell! In case you don't make a new major version anytime soon, I could also split the refactoring from the (breaking) consistency improvement, which means just a few extra lines that could be removed in the next major.

@nodejs/collaborators Can we get some other quick LGTM?

New CI: https://ci.nodejs.org/job/node-test-pull-request/4017/

@jasnell I'll like to get this landed for v7.

CI is passing.

This is getting a LGTM from me, if @mcollina will fix the comment when landing

@mcollina ... ok, I'll be cutting the branch right about at noon pacific today so there's still some time.

the change LGTM

Landed as fd6af98

It would appear this has broken passing null to listen

https://github.com/yoshuawuyts/crash-reporter-service/blob/master/tests/lib.js#L40

Was that intended behavior? If not we should land a fix

edit:

ref --> https://twitter.com/yoshuawuyts/status/820527120740913154

The main discussion is in: #4039 (comment).

Yes it was a wanted fix, as I think that we should validate ports in a consistent manner. Specifically, in node v6 passing null as a port in the option object throws, but not when passing it as an argument.
See the change in the test: https://github.com/nodejs/node/pull/4039/files#diff-8900a04533ee1d4f9930c8ac100a2a96L24.

It has also passed a long amount of CITGM runs for all the v7 releases.

+1 for consistency in validation, but I think passing null as port in option object should not throw.

I would expect calling .listen(function(){}), .listen(null, function(){}) , .listen(undefined, function(){}) , .listen({}, function(){}), .listen({port: null}, function(){}), .listen({port: undefined}, function(){})`, and all the previous when called without a callback, should have same behaviour, and the behaviour should be to treat it as "port argument was not provided (use default)".

Basically, in an options object, we should not distinguish between o{}, o={opt:null}, and o={opt:undefined}, since in all those three, o == null and o == undefined.

@sam-github I'm not convinced about that. We support undefined, because that's what we get when something is not specified. In order to get null, it would have to be explicitly set. IMHO it's more robust against programmer errors in this way. It didn't break a lot of the community either, as what was mentioned was new software.

@mcollina Imagine configuration coming out of node-config YAML files, and default.yaml has a port which is overridden by mcollina.yaml (NODE_ENV=mcollina) which sets port to null in order to turn off the default. Very normal use case imho.

@ronkorving why do not set it to 0? For all valid use cases, this is typed by a human. And 0 is a much more sensible value than null from a SO perspective.

@mcollina its easy to get keys set, config files, default handling, etc. Object.assign, util._extend can both clear keys by setting them to undefined, for example, but can't delete keys.

Can you explain why you think its more robust?

I've found the exact opposite. In Javascript, o={}, o={opt:null}, and o={opt:undefined}, o.opt == null and o.opt == undefined. Its is possible to distinguish between property not set, and property set with value of undefined, but you have to write extra code to do so, so APIs that distinguish between them are harder to document, implement, and use, and lead to subtle faillures in my experience.

@mcollina Setting it to 0 is very explicitly setting it to that value. Trying to unset it so it uses whatever the default may be (in this case 0) has different semantics. You can state the first is always superior, but I guess my point is that there are various ways to look at this (of which at least one case can run into the null problem).

@sam-github I generally think that massively overloaded method are extremely hard to maintain, optimize and keep secure. In this particular case, null was never documented as a possible value in the first place, and an accident of our implementation.

If it was for me, I would remove the default value for port, because it just leads to confusion.

Having said so, fire a PR and we will discuss it there. Even if I disagree, it seems a lot of people care about passing null as a port, so I'll be happy to review that change.

Much of node's API is undocumented, unfortunately, so its hard to argue intentions.

I agree with you on massively overloaded methods, but not here.

if ("PORT" in process.env)
  server.listen(process.env.PORT, ...) // use the port
else
  server.listen(...) // use the default

is, IMO, unfortunate, I'd rather

server.listen(process.env.PORT, ...) // if the env var is not defined, you get the default behaviour

This pattern shows up quite often when loading config, not just env vars, which is why its important to base behaviour on a key's value, not its presence, its why:

var config = {}; // probably read from a config file or DB, note there is no PORT
server.listen({port: config.port}, .. // options.port exists, but value is undefined

should be the same as

server.listen({}, ..  // options.port key does not exist

@sam-github

Just to clarify, this does not work in v6, but it does in v7 with this very change:

var net = require('net')

net.createServer().listen(process.env.PORT, function () {
  console.log('server listening on', this.address())
})

also

var config = {}
console.log(config.port) // => undefined
server.listen(config.port) // you get the default behavior

config.port = null
console.log(config.port) // => null
server.listen(config.port) // it throws, because null is not a valid port

IMHO it's working as you want, with the added benefit of preventing bad values you would have to come from somewhere unexpectedly.