Closed scripthunter7 closed 1 month ago
Hi @scripthunter7,
Thanks for reaching out and for your suggestion. I am not super warm to the idea of exposing isIp
because I see it more as an internal implementation detail and I do not want tldts
to be used as a validation library (I think there are more robust solutions to this use-case in specialized packages).
tldts
's goal is to parse public suffixes from hostnames and as a convenience also supports detecting special cases like IPs but I think it's best to keep the public API restricted to the core mission of the library if possible.
Do you have a specific use-case where having tldts expose isIP
would help you?
Best,
Hi @remusao,
We working with some host-like rules in our parser, and at the moment when I opened this issue I thought it would be good to use tldts
as a single library here as it covers the topic quite well. But I double-checked it, and it seems that not everything is validated in isIp
(e.g. 999 can be in the IP, etc.) - so I agree with you, it's more of an internal, speed-oriented implementation, and maybe it really wouldn't be a good idea to export it in its current form.
Thanks for your reply and thanks for making this great library!
I'm closing the issue
I've noticed that the library exports several helpful functions, such as
getDomain
andgetHostname
. Following this pattern, I would suggest addinggetIp
or export theisIp
function