Modernizing a 100+ Package Monorepo at Opendoor

Taming a 100+ Package Beast: I spearheaded the modernization of Opendoor's JavaScript monorepo tooling, a sprawling ecosystem of over 100 disparate packages. Our legacy setup was a tangled mess: publishing shared libraries to a private NPM registry. This wasn't just complex, it was a triple whammy of pain: bloated CI/CD costs, a huge DevEx burden (no concurrent development of libraries and consumers!), and a general drag on developer velocity. Previous attempts to fix this had fallen short, but I dove in headfirst.

After a rigorous discovery phase (exploring 10+ monorepo solutions) and some serious experimentation, I crafted a custom solution that slashed build times, supercharged developer workflows, and untangled the dependency web. The result? A smooth, efficient monorepo that empowers our teams to build and ship faster than ever before.

The final solution removed the need to publish shared libraries entirely, allowed for developers to live-reload changes to shared libraries when developing consumer packages, allowed for incremental adoption, all while accommodating per-package package managers and lock-files.