When possible, I prefer to upgrade dependencies incrementally rather than making several version jumps. So, we try not to go from React 16 to 19. We go from 16 to 17, then to 18, and finally to 19. The Risks of Jumping Multiple Versions It’s very tempting to jump to the latest release. It feels like time travel; putting your application on the latest in the fewest number of steps. What’s not to like? ...
A policy I favor with dependency management: go forward. Going backward is an exception that we must plan to remedy. Example Consider a CVE in a dependency at version 5.0 (v5.0). We’re advised that v6.0 and v4.0 are safe. Which way should we go, forward or backward? We want to default to forward. Even if we’ve been on v4.0 before and know it is compatible. Even if we aren’t sure that v6.0 is “solid” or if it takes some code changes to implement. ...
Permanently forking a library is something I’ve observed on several teams. But, there are tradeoffs that aren’t always obvious. When to Fork: My Mental Model Here’s my mental model for evaluating when to fork: Dead project: this is the easy one. If the software is open-source and has an accommodating license, this can be a great solution to the “Build vs. Buy” question. Capable team that can maintain it: Got a team of pros who want to maintain a fork of a popular library for years? This might work. The library won’t merge or engage with your patch: You need the project to do X, but it won’t. After a reasonable effort, you might want to fork it. The Risks of Forking When you fork, until you pull from upstream or shut down your forked project, you own the code. You don’t have the maintainer(s) to help you, you don’t have new features from active contributors, and you don’t have enough eyeballs to make most bugs shallow. ...
Unused dependencies are bad: they increase the size of your project, slow down your processes, require upgrades, and send incorrect messages to fellow developers about what’s important. Make your project better by periodically auditing your dependencies, and removing those that are unused. If a dependency is in your bundle and is not being used right now, get rid of it! Legacy codebases are littered with rainy-day libraries. Rip them out and start again. ...
My current favorite command line alias is mgrim, composed of four other aliases. Here’s what it is, and what it does. alias gmr='gco master && gpr && gco - && git rebase master' alias grim='git rebase -i master' alias mgrim='gmr && grim' Starting from a feature branch: gmr - checkout the master branch (gco is a Hashrocket alias for git checkout. Pull from origin/master and try to put my commits in the right place in history (gpr is a Hashrocket alias for git pull --rebase). Checkout my feature branch. Fast-forward my branch to the top of master (as though I had branched off master’s current HEAD. grim - Open an interactive rebase to cleanup everything on my branch (see ‘Squash Your PR’) I use feature branches for work, and use this command right before merging into master. The result? I’m always forced to look at my branch history and squash it down to the minimum, which is good for everyone (including future me). And, I never have a merge conflict with master.