|
|
|
|
|
by dozzie
3875 days ago
|
|
Delegating things to a library you give up control over any bugs the library
has. You can't simply fix the bug like you would do to your code, you either
need to fork the library (maintaining a fork has cost), patch it (maintaining
the patch is not free), or send fixes to its maintainer -- or any combination
of these. Using many dependencies also makes your application a fractal of dependencies.
Library you use has its own dependencies, which have their own dependencies,
which have... And so on. If you happen to want to put your application to
DEB/RPM packages properly, host your app's dependencies locally to isolate
from network outages, or do virtually anything non-trivial with your app, you
hit the list of dependencies very hard. It's not to say dependencies are evil; like any generalization, this would be
simply stupid. But they have their cost, and it's large. You'd better make
sure a library really simplifies your life before adding it to your project. |
|
I find that using tools like npm, nuget, gems, and the like along with github for core libraries makes managing dependencies FAR better than relying on an internal copy of said package in my project, which is just as risky as an internal fork. Yes, there's a chance the package system can be down while you are wanting to deploy.. that's why you prepare on a staging server, and duplicate that to production. Hell with things like docker, you create your container, and run it with environment variables for which environment it's running against.