My rule of thumb is, write it yourself until it's painful, and spend a day looking for a good library to reduce the pain. If you can't find it after a day, or if you found one but it's taking longer than a day to configure it for your needs, try to write one yourself. This rule has not done me wrong yet. It's how I ended up moving away from Mobx and Redux in favor of RxJS and setState (just submitted a post about how to do this), and why I moved from Vue to React. But it is very subjective and subjectivity gets harder the more people you have on a team working on the same code.
I've actually come to prefer the opposite. I'd argue that the liability associated with third-party deps makes them debt. Debt is great for growth and experimentation. It works in a pinch especially if the experiment fails and you can just toss the dependency. So, today I'd rather buy, then build when I know I want to take on the pattern for better ops and long-term ownership.
Do you build? Or do you buy into the support level, the features, the bugs, the availability, the security, etc.