[aethertap]

I will often use things like this, not because I don't know how it's done, but because I have a hope that whoever made it will maintain it and keep it working properly under future changing conditions. Today, it's easy to see if the platform is windows. Later, that may change, and if this code is maintained it will save me headaches. If lots of other people are also using it, there's a very good chance that it will be updated quickly and that weird corner cases I'm not aware of will be already taken care of.

[asdkhadsj]

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.