>Committing external dependencies to source control means tons of bloat to the repos themselves. Want to clone huge_framework just to change a tiny thing?
Oh, geez, the first thing that makes code _legacy_ code is people checking in "slightly modified" library/framework code.
Not to mention different lib versions. Things like java's Spring libs where it seems like the jar layout, names and hosting changes every couple minor versions. Different dependencies that need different versions of things. Different apps in the same ecosystem that rely on newer versions than the legacy in-house libs they are compatible with.
I've put up with a _lot_ of dependency nonsense on many different stacks over the years, and am trying to adapt to devs bringing in NPM modules for dev use, but for sure I've learned that letting devs check in random libs into source control just because its convenient ends up with a lot of problems. That includes java, php, ruby, perl, and python.
That its yet another generation of landgrabbing devs re-inventing a broken wheel, or people just permanently checking in libs for convenience seems like a devils choice.
...until you see the dev that tries to write it all from scratch themselves.
"Oh, geez, the first thing that makes code _legacy_ code is people checking in "slightly modified" library/framework code."
For myself, I consider the ability to have a dependency and cleanly put a patch on top of it, such that the tooling can help me when I'm upgrading the dependency, is a basic requirement.
Few, if any, tools seem to consider this a first-class need. Based on what I've seen, I imagine this is because most people tend to prefer putting in a thousand lines in their own code to contort things around to hack the underlying library to mostly do what they need most of the time even if it shreds every abstraction their code is nominally creating rather than making a three line change in the framework itself, even before we're discussing tooling making it harder to patch. Most of the remainder tend to, as you say, hack the library in such a way that it can not be usefully tracked; for this I would suggest the tooling should be considered at fault.
Oh, geez, the first thing that makes code _legacy_ code is people checking in "slightly modified" library/framework code.
Not to mention different lib versions. Things like java's Spring libs where it seems like the jar layout, names and hosting changes every couple minor versions. Different dependencies that need different versions of things. Different apps in the same ecosystem that rely on newer versions than the legacy in-house libs they are compatible with.
I've put up with a _lot_ of dependency nonsense on many different stacks over the years, and am trying to adapt to devs bringing in NPM modules for dev use, but for sure I've learned that letting devs check in random libs into source control just because its convenient ends up with a lot of problems. That includes java, php, ruby, perl, and python.
That its yet another generation of landgrabbing devs re-inventing a broken wheel, or people just permanently checking in libs for convenience seems like a devils choice.
...until you see the dev that tries to write it all from scratch themselves.