Stack Tool · devtools
Turbo
Turbo is the build system that orchestrates tasks and caches outputs across my monorepo, ensuring fast, consistent builds and type-checks for every Total Ventures product.
Visit turbo.build ↗Turbo powers the build and test cycles for every Total Ventures product, leveraging content-addressable caching to make incremental changes feel instant across a multi-package monorepo.
What it is
Turbo is a high-performance build system for JavaScript and TypeScript monorepos. Its core value lies in its content-addressable caching and task orchestration. When you run a task like `build` or `type-check`, Turbo hashes the inputs (source code, dependencies, config files). If those inputs haven't changed since the last run, it retrieves the output from its local or remote cache instead of re-executing the task. This means a full type-check across 19 packages for brands like Total Formula 1, Pregnancy Power Hour, and Inky can complete in under 200ms when nothing relevant has changed. It understands the dependency graph between packages, so it can run tasks in parallel and only re-run what's necessary.
How I use it
Every CI run and every local validation in Total Ventures goes through Turbo. For local development, `turbo run dev` starts all necessary services, while `turbo run type-check` quickly validates code across the monorepo. In CI, it's the first layer of defense. When an AI agent pushes a change, GitHub Actions invokes Turbo. It determines which packages need rebuilding or re-testing based on the cache. This is critical for agentic engineering workflows — the faster the feedback loop, the more iterations an agent can complete. If a build fails, Sentry captures the error, and a Slack notification is sent, but the initial detection is often Turbo reporting a task failure. My custom agent orchestration layer, Mercury, also leverages Turbo's output caching to ensure that subsequent agent runs don't re-process already validated code.
Why this over alternatives
I've learned the hard way that managing builds in a growing monorepo without a dedicated tool leads to slow, inconsistent developer experiences. Alternatives like Lerna offer package management but lack the robust, content-addressable caching that Turbo provides. Running individual `pnpm` workspace scripts is fine for small projects, but it quickly becomes inefficient when you have interdependent packages and want to avoid redundant work. Turbo's configuration, primarily through `turbo.json`, is declarative and straightforward. It's a system architected for speed and consistency, which translates directly into saved time and reduced frustration, especially when working across multiple distinct product lines.
Where it falls short
While powerful, Turbo isn't without its nuances. Initial setup and understanding the caching mechanisms can take some time. Incorrectly configured `outputs` or `dependsOn` in `turbo.json` can lead to stale caches or unnecessary re-runs. Debugging cache misses can sometimes be opaque, requiring a deeper dive into the logs. For a truly simple monorepo with only a few packages and no complex interdependencies, the initial overhead might feel disproportionate, but for Total Ventures' multi-product structure, the benefits far outweigh these considerations.
FAQs
- Is Turbo worth the overhead for a solo developer?
- For a monorepo with multiple distinct packages, yes. It pays back quickly by making incremental builds and type-checks near-instant, saving significant time daily.
- How does remote caching work with Turbo?
- I use Vercel's remote cache. It stores build artifacts in the cloud, so CI runs and other machines can pull pre-built outputs, avoiding redundant work.
See how I run a multi-brand studio with this stack.
See the full stack →