Which part of the api exactly are you referring to? The plugin api or the node api?

@dignifiedquire No particular preference for API.
I was thinking of something like this

globalEmitter.on('karma_server_port_bound', function(port) {
});

Didn't test, but looks like there is another way:

webServer.on('listening', function() {
  // "config.port" is bound
});

The only problem here is that it depends on karma/lib/server.js implementation, i.e. that "config.port" is increased by one after each unsuccessful binding attempt.

@segrey I've implemented a solution in #1485 for you, with that you can do

var Server = require('karma').Server
var server = new Server(config, done)

server.once('browsers_ready', function () {
  var alwaysSafePort = server.get('config').port 
})

@dignifiedquire Sorry for the late reply. Thanks for looking into this. Really appreciate it.
Unfortunately, browsers_ready event is not fired exactly after webserver port binding, there could be a delay until browsers are ready. Nevertheless, browser_ready is useful event for IDE: WebStorm guesses this very moment using 'browserConnected' events. Thanks a lot for introducing it.

About webserver port binding event: I'm thinking of using

webServer.on('listening', function() {
  var actuallyBoundPort = config.port;
});

What do you think about legitimating this way?
By legitimating I mean adding it to https://github.com/karma-runner/karma/blob/master/docs/dev/04-public-api.md.

Sure sounds good, let's use 'webserver_listening' event on the server to propagate the event. are you up for a quick PR on it?

I don't think a special event like webserver_listening is really needed. IMO, listening to http server events is quite clear. Also, listening in this way is backward compatible up to karma 0.10 (https://github.com/karma-runner/karma/blob/v0.10.0/lib/server.js), so no code changes needed.

The only thing I'd like to have is legitimating this way to protect from breaking changes. If a breaking change is needed, then this way will be supported along with a new way for at least one version.

It's not needed, but I want all events to be on the Server object, rather than exposing the individual components, as that is much larger surface area to support if I have to ensure that the webserver object is always exposed.

Makes sense. Will create a PR.

@segrey In latest version of karma we emit event 'listening' when webServer started, seems it should fix this issue and we can refactor this code.

I think we can close this issue as fixed, @segrey what are you think? :)

Related issue #1874

Thanks, great! That's just what's needed. For backward compatibility with previous karma versions webServer.on('listening', ...) will be used.

@segrey No problem :)