3 ms·

IMO the best way to move to the next generation of dependencies is through tooling. Instead of ignoring node_modules in source control, why don't we commit it

• petetnt 11y ago
  > I haven't thought about the implications of committing external packages to your own source control at all. I'm guessing I'm missing something. 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? Well too bad, you'll need to clone the hundred megabytes of external dependencies too. Multiple libraries/frameworks/modules containing same versions of same modules? Too bad, everyone needs to commit their dependencies. Frameworks shouldn't commit their dependencies then? Or just libraries? Or just modules? Where is the line and what are the rules? Why not just handle dependencies manually? Because that's a pain in the ass and exact reason why package managers exist in first place.
  • scrame 11y ago
    >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.
    • jerf 11y ago
      "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.
• endergen 11y ago
  This doesn't play well with repos that require native compilation. I'm with you on this approach if you stick to using all pure javascript modules.
• nailer 11y ago
  Commit the shrinkwrap file.