[brightball]

You’re not wrong. Part of it is the willingness of people to reach for a dependency that amounts to a few lines of code to avoid.

It would be nice if there was a tool that could help you identify just how much of each dependency you actually depend on so you could trim it.

[joshuamorton]

These things all exist if you use something like bazel/pants/buck to manage your dependencies. When you can construct a DAG of the entire dependency structure you can see exactly how much you depend on any given thing (and get fun dot-graphs of it!). But that requires being precise with dependency declaration in a way that a lot of people don't want to be.

[geezerjay]

> But that requires being precise with dependency declaration in a way that a lot of people don't want to be.

Some programming language stacks already fix that problem in a transparent way. Take Microsoft's .NET Core+Nuget stack. Developers can add packages to a project without specifying a version number (implicitly it's the latest release) and dependencies are checked when all dependencies are restored.

IIRC Rust's cargo also follow a similar approach, and so do npm and yarn. So, that's pretty much standard at this point.

[hliyan]

Is there something that is akin to development-time tree-shaking (as opposed to build time)? i.e. you pull a copy of the specific library functions directly into your source?

[tatersolid]

This is called “vendoring” your dependencies (taking a snapshot into your SCM), and has been common practice for about 30 years. Long before NPM and other language-specific package managers.

Tools for managing vendor branches or sub-trees abound, but good old svn:external and scripts work for most use cases.

[maerF0x0]

one of the go proverbs is a little copying is better than a little dependency. [1]

Also go vendoring tools usually trim the repos down to the packages you import.

[1]: https://go-proverbs.github.io/