Funnily enough, I was just digging through my current project's dependencies and he's slipped in via a Rollup plugin which uses his "globby" package, which in turn uses his "slash" package.. Slash is about 5 lines of code, which is roughly 4 more than most people need for what it does.
I vastly prefer to use libraries with 0 dependencies but I never quite manage it, so I end up with the same problems as everyone else.
For years, the bane of my existence was always lodash. Import one tiny utility and it brings along 15 of its closest friends. You can't get away from it. It was built so incredibly modularly, that it has to import a bunch of other things. Now most folks will quickly rush to its defense and tell you that Webpack should be able to tree-shake it well enough. My actual experience is that it was a tremendous waste of my customers' bandwidth. Seeing LoDash as a dependency of anything I use is an immediate NOPE for me. I've yet to see anything it provides that I couldn't just do myself.
It's an unpopular opinion for some silly reason. It's like when Guava or Apache Commons was included on every single Java project in the 2010s. "It's just so much easier to use a well-tested library". That line of thinking is what got us here.
I'm the opposite, I tend to be relieved when I see lodash as a dependency. In any normal sized project I'm probably already using it, or it's already a dependency of a dependency. I trust it a lot more than a hundred tiny libs by random authors, both in terms of sketchy behaviour and reliability/performance. If I need to target platforms which don't support modern JS I vastly prefer to stick to lodash than use a bunch of polyfills of unknown quality.
The individual functions are installable separately from NPM, and lodash-es should tree-shake quite well, but I do know what you mean about it dragging in its internal dependencies so you end up with a 15kb of lodash code for a single thing. I probably wouldn't love to use it client-side on an ordinary website, were I to make one.
He’s a prolific open source author that traditionally had a lot of modularization in his packages—though I think he has started to move away from it recently. He talks about it here: https://blog.sindresorhus.com/small-focused-modules-9238d977...
Most projects will include at least one package by him in the dependency tree.