3 ms·
> to be in control of the dependencies Maybe I'm out of touch, but I think control over dependencies is underrated. It's not just about freezing and pinning. T
by RossBencina 2mo ago
> to be in control of the dependencies
Maybe I'm out of touch, but I think control over dependencies is underrated. It's not just about freezing and pinning. There should be better tooling to support the whole dependency evolution pipeline. For example updates should be reviewed/ingested/integrated/validated based on local policy not based on source release schedule.
- solatic 2mo agoThis is why some projects will vendor their dependencies - changes within the dependency itself will also be reviewed, and it's easier to locally maintain patches to those dependencies until the patches can be upstreamed. The problem is, there's a difference between doing that for a handful of C or Go libraries, versus trying to vendor thousands of NPM libraries and all of their interdependencies. So it's very ecosystem dependent.
- RossBencina 2mo agoAgreed. Your self-managed vendoring example is quite near one end of the continuum. I'm suggesting that there might be space for better tooling from there all the way to the NPM end. For example, automated and/or collaborative triage and review of change sets so that you don't see the changes you don't care about, but can easily review and integrate critical fixes.