I mostly always use the same libraries and have them forked. And as little as possible. We have our own substantial tooling built on top of those libraries buil

I mostly always use the same libraries and have them forked. And as little as possible. We have our own substantial tooling built on top of those libraries built up over the last 15 years. The only modern thing we use (now for everything) is CLOG. I wish someone would write something better, but on the other hand; we can quickly build anything we need with the tooling we have without the need for libraries. Basically; set up what you need and consider it 'your responsibility' now. I think that's the healthy way to handle libraries anyway, in any ecosystem; bad actors are everywhere and 'just updating/upgrading' stuff is such a bad idea usually. Don't get me wrong; I do feel your pain when you want to try out something; you have to have some understanding or how to work with CL and the tooling to get up projects that have rotted over time, but it's not hard. I recently added a library that is 12 years old to our project and it took a few minutes to fix some of the deps; now it's in our repos and works perfectly. For other work, I have to work in the nextjs / npm ecosystem and good lord am I happy CL doesn't have that; almost every library is terrible; I became a contributor to 100s of npms over the years because they almost all truly suck. Just 'quickly do this and that, npm publish, alright works for me kthnxbye'. Massively (over-invested some of them with millions of VC$) used projects in NPM contain seriously painful bugs that remain open for months or years (or wontfix... it's a bug mate, not a feature). Most major ones take me more time to debug and fix than I would write them from scratch in our CL tooling. Sorry for the rant.