Tooling migrations don't have to take weeks anymore
I used to block out weeks for tooling migrations. Now I let Claude Code run in the background, check in when it's done, and pair with it to understand what changed.
When you're configuring a monorepo with lerna, you might consider writing your build scripts like this:
It makes sense, initially! You're probably thinking, why wouldn't I want to build all my scripts concurrently, rather than running each build one-by-one?
The above build script actually works wonderfully, until you build a package that relies on another package in your monorepo. Then, if you're anything like me, your linter might warn you:
You'll have no idea why, because you probably have the packages already built locally. This'll only be caught in CI, if you have CI. Or it will be caught when one of your teammates pulls down master, and sees this error for themselves! Or worse, when a consumer of your library can't consume it!
You need to make sure that your packages are built according to their dependency graph. For example, if package1 imports package2, you need to build package2 first, otherwise package1 won't be able to find package2.
All you have to do is be a little less fancy:
I used to block out weeks for tooling migrations. Now I let Claude Code run in the background, check in when it's done, and pair with it to understand what changed.
Frontend technical debt doesn't just slow down developers. It undermines your entire business through user attrition, legal risks, and revenue loss. Here's how to spot and communicate these hidden costs.
How I used Conductor and Claude to streamline my team's Dependabot review workflow — and how a colleague turned it into a GitHub Action