4 ms·

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

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.

hliyan 8y ago
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 8y ago
  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.
joshuamorton 8y ago
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 8y ago
  > 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.
maerF0x0 8y ago
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/ https://go-proverbs.github.io/

hliyan 8y ago

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 8y ago
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.

joshuamorton 8y ago

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 8y ago
> 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.

maerF0x0 8y ago

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/ https://go-proverbs.github.io/