<https://nesbitt.io/2025/12/24/package-managers-ke...
# random
b
I actually don't object to this practice
I think the lesson here is that decisions made in the past at some scale should be revisited later. But if you're use-case makes sense to just piggy-back, and for the foreseeable future that'll work out... 🤷‍♂️
w
Yeah, I like the history lesson - it's super fascinating. I don't have much objection to package managers pointing to git repos in general (as in, the target of a package dependency should rightly be allowed to be source control, though ideally not required to be). However, the flip side of the discussion for me is more a matter of knowing what doesn't scale/can't scale ahead of time and planning for those provisions early (though not necessarily executing on them). The sad truth of the matter is that thinking about performance when it becomes critical typically makes the problem harder, when there might just be so much technical debt that it can't be accomplished (see: any "re-write it in rust" meme)
In open source, it's one thing - but in the commercial world, this problem can be even worse, because unless there is a tangible, monetary incentive - so many companies just don't want to fix perf problems (ESPECIALLY not dev tool perf problems 😢 )