Yea, I agree completely. While I tend to reinvent plenty of wheels, I don't find the idea of importing a package designed for one small task, bad.
(edit: missing word)_Especially_ if it's used by a ton of repos. If, as your example says, something changes where `is-windows` needs to be updated it's likely to either be updated or break so many codebases that someone will update it.
There's a bit of chaotic safety in relying on a web of dependency trust like this. On one hand more people invested in the behavior of a simple package gives you more confidence. On the other hand, it means more developers are depending on more packages, introducing possibly more brittle behavior.
The latter (brittle behavior/deps) has been my experience fwiw. While I don't dislike the idea of `is-windows`, I do dislike introducing more points of random failure. In general if I don't have the idea that my own implementation of something like `is-windows` is likely to need maintaining then I'm happy to do it myself and remove a dependency.
Coming from Rust mostly, but I wonder if the safety of the language aids this problem too. For example, I imagine `is-windows` level of dependencies is far less problematic in Rust than NodeJS.