I've had some contact with Docusaurus and from my experience the Sphinx and reStructuredText combo is a much better solution to creating a robust, maintainable, cross-linked-to-nth-degree documentation where you actually can "focus on your content".
Bonus points if you prefer to not deal with the JS ecosystem and prefer Python.
The main downside is that while reST is well-suited for extending the syntax actually writing Sphinx extensions is, subjectively, significantly more arcane than writing React components/MDX plugins.
> Wouldn’t it be simpler and more consistent to have a first parse the IP into an internal format then perform all logic on that?
So not speaking about this library specifically but yes, separating the address parsing part (https://www.netmeister.org/blog/inet_aton.html is a fun read) from the "is this address considered private?" part should make things much simpler.
Vast majority of related code in this space that I've seen works like that. I'm actually struggling to come up with counterexamples.
> The CVE has to do with the utility not correctly identifying private IP addresses supplied to it in a non-standard format, such as hexadecimal. This would cause the 'node-ip' utility to treat a private IP address (in hex format) such as " 0x7F.1..." (which represents 127.1...) as public.
Things aren't necessarily as simple as they appear.
There's this thing called IANA IPv4 Special-Purpose Address Registry[1] and it lists some address ranges labeled Private-Use, it's the usual suspects: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
The table also has a Globally Reachable column. Some special ranges, including but not limited to Private-Use above, have Globally Reachable set to false.
Some others, like Direct Delegation AS112 Service (I don't know what it actually is), are listed as actually Globally Reachable.
So I'd say there are at least three plausible interpretation of the word "private" in this context:
1. IPv4 or IPv6 address, listed as a special range and Globally Reachable = false (caveat: for some IPv6 ranges there can be N/A in that column[2], more choices to make)
2. These IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
3. All special ranges from [1] and [2], we don't want to try to contact any of these
For example Python's ipaddress mostly follows interpretation 1 while Rust standard library[3] and Python's netaddr[4] (disclosure: I maintain it) effectively follow interpretation 2.
From the point of view of a library author the semantics of what's private, what's public, global, etc. needs to be documented very well and examples provided.
From the point of view of a library user the documentation needs to be consulted (and tests performed) to make sure the library semantics match assumptions/expectations.
Looks like a great initiative – I wish there was a reliable TS/JS equivalent of https://docs.rs (even considering rustdoc's deficiencies[1]).
I went through this exercise recently and so far my experience with trying to produce documentation from a somewhat convoluted TS codebase[2] has been disappointing. I would claim it's a consequence of the library's public (user-facing) API substantially differing from how the actual implementation is structured.
Typedoc produces bad results for that codebase so sphinx-js, which I wanted to use, doesn't have much to work with. I ultimately documented things by hand, for now, the way the API is meant to be used by the user.
Bonus points if you prefer to not deal with the JS ecosystem and prefer Python.
The main downside is that while reST is well-suited for extending the syntax actually writing Sphinx extensions is, subjectively, significantly more arcane than writing React components/MDX plugins.
A recent discussion on this topic, part of the "I prefer rST to Markdown" submission: https://news.ycombinator.com/item?id=41120772