Monorepo tooling isn't a technical decision. It's a maintenance decision.
In 2024 I migrated our design system monorepo from Lerna to Lerna Lite. The diff was small in the packages and huge in the lockfile: 3,568 lines added, 11,647 removed. The reason: full Lerna was heavy, and all we used was publish automation and the changelog. Worse, it didn't work with pnpm's workspace: protocol. Without it, internal dependencies were pinned to fixed versions in package.json (cortex-react pointed to cortex-core 0.3.1), and a package from our own repo got downloaded from npm again. With Lerna Lite everything became workspace:*: local packages during development, and the real version written in at publish time. Along the way, yalc and the lerna run scripts went away, replaced by pnpm --filter.
Two years later, a different kind of debt: seven packages repeating the same dependency versions. I moved everything to the pnpm catalog. Today that's 23 dependencies declared in a single file, and every package.json points to catalog:.
In the same commit I added an AGENTS.md at the root and one in every package (eight in total), explaining what the package does and how to run it. It helps new teammates and coding agents alike.
As a tech lead I learned to change the question. Instead of "what's the best tool?", I ask: "who will understand this a year from now, without me?"
In mentoring, that's the criterion I try to pass on: measure a tool by what it costs the next person.
Which tooling decision would you make differently today?
Top comments (0)