Yup for sure, 100%. Pulling in a library every time you don't know how to do something is a choice. Only pulling in dependencies that have 10,000 Github stars or are in every react Youtube video without evaluating alternatives is also a choice. I learned to be way more discriminating about npm libraries from a tech lead a few years ago, and to be honest it's one of the best lessons I've learned in a while.
But it is not a viable choice anymore to “not include this useful dependency, because its dependency tree is huge, so I will just rewrite it from scratch”, which is what practically happens in most cases. No one deliberately imports bullshit like leftpad on the root level. If you use react alone it will probably already make enough of a mess that windows’s file operations will take considerable time on your node_modules folder, which is ridiculous in and of itself.
We're saying "think about each dependency you're considering pulling in. Maybe have a quick browse through the code. Is it a gigantic hot mess? Is it tiny and elegant? Does it only have 3 downloads/week on npm? There are lots of things you can do before deciding to rewrite it yourself, but yes, I argue there are definitely some dependencies where that is the right call. But also, YMMV - it depends on your team and resources too.
there are room between huge dep tree and rewriting everything, that's where we should aim
for leftpad, even if I know it's just an example, there's a native String#padStart, and else lodash is pretty small, most mainstream libs have few deps actually
Tolerating an iceberg of bad habits under a surface of abstractions is a way to get up to speed on something fast, but you eventually have to invest time learning better ways to do things. Except in web development where it's normal to send multi-megabyte blobs to the browser.
If you always in include 'vanilla' as a verbatim search term when looking for Node.js tutorials you'll get better results that tend to avoid that problem.