Hmm. Thinking on it more, I guess I'm an "import.*" guy from a philosophical perspective. It's abstraction leak.
...at work there's a whole group (who I support) that cope with the layers of external dependencies our code has, some for shipping, some for internal development, etc., etc. There are some thorny problems in there but they all basically boil down to compile/link time, disk space, overlapping solutions, or DLL Hell (where two libraries depend on different versions of the same library).
For smaller projects, if I can avoid the last two, and the first two aren't that bad, then I just want to import everything I need so I don't have to think about what I'm importing. The hit to compile times and shipping sizes is not as important to me as things like:
* reduced programming effort * solid code -- I presume, right or wrong, that libraries are more debugged than my own off-the-cuff solution will be * the lessons implicit in well-thought-out libraries -- where they've already caught the three stupid things you can do and put up warning signs * in some cases, connection to a community of like-minded coders
Masking dependencies, however, is a bit dangerous. NPM makes it dead easy (as with other package managers) to include something that pulls in a tree of a hundred other libraries. It'd be nice to have *some* sort of insight into that before selecting a dependency, potentially a "library store" where you can go and shop for solutions to a problem based on what they pull in...
no subject
...at work there's a whole group (who I support) that cope with the layers of external dependencies our code has, some for shipping, some for internal development, etc., etc. There are some thorny problems in there but they all basically boil down to compile/link time, disk space, overlapping solutions, or DLL Hell (where two libraries depend on different versions of the same library).
For smaller projects, if I can avoid the last two, and the first two aren't that bad, then I just want to import everything I need so I don't have to think about what I'm importing. The hit to compile times and shipping sizes is not as important to me as things like:
* reduced programming effort
* solid code -- I presume, right or wrong, that libraries are more debugged than my own off-the-cuff solution will be
* the lessons implicit in well-thought-out libraries -- where they've already caught the three stupid things you can do and put up warning signs
* in some cases, connection to a community of like-minded coders
Masking dependencies, however, is a bit dangerous. NPM makes it dead easy (as with other package managers) to include something that pulls in a tree of a hundred other libraries. It'd be nice to have *some* sort of insight into that before selecting a dependency, potentially a "library store" where you can go and shop for solutions to a problem based on what they pull in...