Fork your dependencies
Mitchell Hashimoto@mitchellhFork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies.
- ▪Mitchell Hashimoto@mitchellhFork your dependencies, trim them to only your use case, never update unless it breaks for your users.
- ▪I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored).
- ▪If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies.
Opening excerpt (first ~120 words) tap to expand
Mitchell Hashimoto@mitchellhFork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10+ years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at X (formerly Twitter).
Discussion
0 commentsMore from X (formerly Twitter)
