Add ip validation

[remusao]

This PR addresses #104. Changes:

• Introduce a fast ip validation to check if a hostname is also an IP, and return consistent results.
• Extend benchmark.js to show performance when a valid hostname is directly given as input (no URL parsing necessary) vs. when a URL is given (parsing necessary).

Here is a more detailed view of the current performance:

>>> -------------------- <<<
>>> Only valid hostnames <<<
>>> -------------------- <<<
While interpreting the results, keep in mind that each "op" reported by the benchmark is processing 16 domains
tldjs#isIp x 4,543,750 ops/sec ±0.97% (91 runs sampled)
tldjs#isValid x 528,309 ops/sec ±0.48% (95 runs sampled)
tldjs#extractHostname x 485,646 ops/sec ±1.42% (93 runs sampled)
tldjs#tldExists x 125,752 ops/sec ±0.81% (90 runs sampled)
tldjs#getPublicSuffix x 65,652 ops/sec ±1.25% (90 runs sampled)
tldjs#getDomain x 62,128 ops/sec ±0.56% (95 runs sampled)
tldjs#getSubdomain x 58,663 ops/sec ±0.90% (93 runs sampled)
tldjs#parse x 49,101 ops/sec ±0.96% (92 runs sampled)

>>> ----------- <<<
>>> Random URLs <<<
>>> ----------- <<<
While interpreting the results, keep in mind that each "op" reported by the benchmark is processing 16 domains
tldjs#isIp x 4,270,354 ops/sec ±1.30% (87 runs sampled)
tldjs#isValid x 1,389,816 ops/sec ±0.70% (92 runs sampled)
tldjs#extractHostname x 23,037 ops/sec ±1.26% (86 runs sampled)
tldjs#tldExists x 13,854 ops/sec ±0.88% (94 runs sampled)
tldjs#getPublicSuffix x 10,905 ops/sec ±1.00% (96 runs sampled)
tldjs#getDomain x 11,018 ops/sec ±0.58% (92 runs sampled)
tldjs#getSubdomain x 11,081 ops/sec ±1.08% (96 runs sampled)
tldjs#parse x 10,665 ops/sec ±0.58% (95 runs sampled)

[remusao]

If this seems reasonable to you, I will also need to update the README with the extra fields in .parse's result.

[remusao]

It seems that whatwg-url needs ES6 :/

[thom4parisot]

@remusao maybe the URL parser could be configured as you did for the hostname extraction. This way the strictness cost is taken only by people who need id.

[remusao]

@oncletom Yes why not! Although technically speaking, the url parsing is done inside of extractHostname, so it's already configurable, but at a high level only. What do you think should be the default implementation, if we were to propose several options?

[remusao]

I will revert the change on the parser and only do the ip validation for this PR. Then we can change the parsing in another PR later since that does seem to require a bit more work than expected!

[remusao]

@oncletom Done, but it seems that is-ip needs ES6 as well... So, I was thinking, do we actually need to know if a hostname is a valid ip address? The goal is just to be consistent and not try to extract a suffix on something that is not a hostname. We could then just check if the hostname is probably an ip, which would be very fast. I think it's ok if we don't expose this in the public API of the library and just use it internally. This way we also avoid introducing any extra dependency.

[thom4parisot]

Agreed, I was thinking about it earlier for #107/#106 and did not feel the need to add extra values in the response which are not really related to the purpose of tldjs.

The IP can be checked by a third party module on the hostname field.

[remusao]

@oncletom Done, let me know what you think.

[thom4parisot]

Would it make a difference if there is a port in the IP address?

[remusao]

Not really. isIp will just check that some properties of the hostname that usually indicates an ip address are met. The port would be stripped during the parsing of the URL itself, before we check if the input is an ip so that should not be an issue in practice.

[remusao]

@oncletom Is there any other change needed for this PR?

[remusao]

@oncletom Sorry to bother, I updated the README + added a few comments. Let me know if you think it could be merged, or if it requires any change.