Cannot use configPath and name

[mmenozzi]

Hi,
I'm trying to use only configPath and name to configure my tunnel.

Given this ngrok config:

# /path/to/ngrok.yaml
authtoken: *****
tunnels:
  myapp:
    addr: 8000
    proto: http

And this code:

    const ngrokUrl = await ngrok.connect({
        name: 'myapp',
        configPath: '/path/to/ngrok.yaml',
    });

I'd expect to have a tunnel open on port 8000. Instead if I open the ngrokUrl I see that the tunnel is open on port 80.

I think this happens because of this default function:

ngrok/index.js

Lines 21 to 29 in b61ebcf

	function defaults (opts) {
	opts = opts || {proto: 'http', addr: 80}
	if (typeof opts === 'function') opts = {proto: 'http', addr: 80};
	if (typeof opts !== 'object') opts = {proto: 'http', addr: opts};
	if (!opts.proto) opts.proto = 'http';
	if (!opts.addr) opts.addr = opts.port || opts.host || 80;
	if (opts.httpauth) opts.auth = opts.httpauth;
	return opts
	}

If the input opts is:

{
    name: 'myapp',
    configPath: '/path/to/ngrok.yaml',
}

The output will be:

{
    name: 'myapp',
    configPath: '/path/to/ngrok.yaml',
    proto: 'http'
    addr: 80
}

And I think that the addr: 80 wins over the config file.

[philnash]

I have been thinking about this issue since you raised it and I wish I'd just started work on it earlier.

You are right that the name is effectively overwritten by the addr and proto, however that's not the whole story.

When this module starts a tunnel, it starts the ngrok service and then uses its REST API to make requests to it. To start a tunnel you make a POST request to the /api/tunnels endpoint with the options for your tunnel. The parameters you can pass to this API are listed in the tunnel definitions section. Note, however, that name is not a parameter. Tunnel definitions within the config file have names, but name is not a parameter we can pass to the ngrok API.

So, to fix this we actually need to read the configFile and the config from the named tunnel within the config. Now I've finally worked this through in my head with the code (rather than thinking about it offhand every once in a while) there is a concrete direction for this.

There are some places where there is some ambiguity though. What errors should be thrown if there is no config file in the given location (or default location)? What errors should be thrown if the named tunnel doesn't appear in the config or should we fall back to the defaults that this module already provides ({ proto: "http", addr: 80 })? If a named tunnel is missing a proto or addr (the two required parameters in the API) do we fall back to the defaults?

I'm inclined to change the existing behaviour a bit and throw errors if a name is passed and sufficient tunnel details can't be found. The potential for surprise is greater when you fall back to defaults. If, for example, I tried to open a tunnel that I had misspelled, I would expect it to open with the settings in the config file, but instead it would open an http tunnel for port 80. I'd prefer to see an error with a good explanation here ("Could not find config for named tunnel ${name}").

Updating this will be a breaking change regardless as we need to introduce reading and parsing the config file. I am currently working towards releasing version 4. I will continue now I have this direction.