Tool Guides
Purpose and Scope
The Tool Guides page is the entry point for integrating development tools with Turborepo. Its job is not to replace each tool’s own documentation; it helps you decide where a tool belongs in a monorepo workflow and which Turborepo-specific guide to read next. The source page identifies this area as an overview for learning how to use favorite tools in a monorepo, with a summary focused on browsing guides for popular development tools. In practice, this means the page is a routing layer between Turborepo’s core task model and tool-specific setup details.
Sources: apps/docs/content/docs/guides/tools/index.mdx
Turborepo treats external tools as part of the same repository-wide workflow as application and package scripts. Linters, formatters, test runners, type checkers, database generators, component systems, and container tooling usually start life as package scripts, then become Turborepo tasks when they need dependency ordering, caching, filtering, or CI orchestration. The overview’s first sentence is intentionally broad: Turborepo works with all favorite tooling. The useful interpretation is that Turborepo coordinates tools rather than owning them, so integration work usually centers on task boundaries, inputs, outputs, and repeatability.
Relevant Source Files
- apps/docs/content/docs/guides/tools/index.mdx — Defines the Tools overview page metadata, reader-facing description, related links, and the list of tool guide cards.
- apps/docs/content/docs/guides/tools/meta.json — Provides the documentation-section page metadata for the tools guide directory.
Tool Guide Catalog
The Tools overview exposes a curated catalog of common integrations: Biome, Docker, ESLint, Jest, Oxc with oxlint and oxfmt, Prisma, shadcn/ui, Storybook, TypeScript, and Vitest. This catalog is useful because these tools represent different integration shapes. Some, like ESLint, Biome, Oxc, TypeScript, Jest, and Vitest, usually run as repeatable validation tasks. Others, like Storybook or shadcn/ui, often participate in development, build, or generation workflows. Docker is different again because it frequently consumes Turborepo output through pruning and dependency-layer optimization.
Sources: apps/docs/content/docs/guides/tools/index.mdx
The related links in the page metadata call out ESLint, TypeScript, Vitest, and Docker as especially important follow-up guides. Those four cover a wide range of recurring monorepo problems: enforcing code quality across packages, sharing compiler configuration, caching test work, and building deployable artifacts efficiently. If you are new to tool integration in Turborepo, start with the guide that matches the task you already run locally. After that, compare another guide with a different execution pattern so you can recognize which concerns are tool-specific and which are Turborepo configuration concerns.
System-to-Code Mapping
| Documentation concern | Source-backed location | What it means for readers |
|---|---|---|
| Page title and description | apps/docs/content/docs/guides/tools/index.mdx | The section is an overview for using tools in a monorepo. |
| Product and content type | apps/docs/content/docs/guides/tools/index.mdx | The guide belongs to the Turborepo docs and is meant as an overview, not an API reference. |
| Related guide emphasis | apps/docs/content/docs/guides/tools/index.mdx | ESLint, TypeScript, Vitest, and Docker are highlighted as related next steps. |
| Tool cards | apps/docs/content/docs/guides/tools/index.mdx | The page links to individual guides for Biome, Docker, ESLint, Jest, Oxc, Prisma, shadcn/ui, Storybook, TypeScript, and Vitest. |
| Directory metadata | apps/docs/content/docs/guides/tools/meta.json | The tools directory participates in the docs navigation structure. |
The source shape is deliberately simple: frontmatter declares the reader promise, and cards enumerate the guides. That simplicity is important for documentation maintenance. The overview should remain stable while individual tool pages evolve with their ecosystems. For example, a TypeScript guide can focus on project references and shared configuration, while a Docker guide can focus on build contexts and pruned workspaces, without turning this overview into a long mixed reference. The overview therefore acts as a conceptual map rather than a configuration manual.
How Tools Fit Into Turborepo Tasks and Caching
When you add a tool to a Turborepo workspace, first decide whether it produces durable outputs, validates source files, starts a long-running process, or generates files that other tasks consume. A formatter check or linter usually has no build artifact, but it still benefits from consistent invocation and CI filtering. A test runner may produce coverage output or simply return a pass/fail result. Type checking often depends on upstream package builds or declarations. Docker workflows may depend on pruned workspace contents and package-manager lockfiles. These distinctions drive how the tool should be represented in task configuration.
The second decision is whether the tool is deterministic enough to cache. A deterministic task should produce the same result for the same declared inputs, dependency graph, package manager state, and environment. Validation tools and test runners are usually good candidates when their configuration files and source inputs are included correctly. Development servers and watch processes are different: they are valuable Turborepo tasks for orchestration, but they are not usually cached as completed work. The individual tool guides are where readers should look for concrete configuration patterns, because each tool has its own input files, generated directories, and runtime assumptions.
Choosing the Right Guide
Use the catalog by matching your immediate problem to the closest tool family. If your repository needs linting or formatting, begin with ESLint, Biome, or Oxc. If your problem is compiler consistency across apps and packages, read TypeScript. If you want fast feedback from unit or integration tests, use Jest or Vitest depending on your test runner. If you are building UI documentation or isolated component development, go to Storybook. If you are managing database client generation, Prisma is the more relevant path. If deployment image size or dependency installation is the bottleneck, Docker is the guide to read.
Sources: apps/docs/content/docs/guides/tools/index.mdx
A useful workflow is to make the tool run correctly in one package first, then lift it into the monorepo task graph. That keeps tool-specific errors separate from Turborepo configuration issues. Once the script works, decide what upstream work it depends on and whether downstream tasks consume its outputs. Then make the task cacheable only when the inputs and outputs are explicit enough to be safe. This sequence prevents overfitting Turborepo configuration before the underlying tool behavior is understood, and it also makes CI failures easier to diagnose.
Reference: Listed Tool Guide Targets
- Biome: /docs/guides/tools/biome
- Docker: /docs/guides/tools/docker
- ESLint: /docs/guides/tools/eslint
- Jest: /docs/guides/tools/jest
- Oxc (oxlint, oxfmt): /docs/guides/tools/oxc
- Prisma: /docs/guides/tools/prisma
- shadcn/ui: /docs/guides/tools/shadcn-ui
- Storybook: /docs/guides/tools/storybook
- TypeScript: /docs/guides/tools/typescript
- Vitest: /docs/guides/tools/vitest
Next Steps
After reading this overview, move to the tool-specific guide that matches the script you are trying to coordinate. For a first Turborepo integration, ESLint, TypeScript, Vitest, and Docker are strong starting points because the overview highlights them as related pages and they demonstrate common task categories: linting, type checking, testing, and deployment packaging. Once one guide is implemented, revisit your turbo.json task definitions and ask whether each tool has clear dependencies, declared inputs, expected outputs, and appropriate cache behavior. That review is the bridge from simply running tools to running them well in a monorepo.