Configure turbo.json tasks, dependsOn with ^build, content-based caching, outputs globs, and Remote Caching for monorepos
0 / 5 completed
1 / 5
What does the tasks (formerly pipeline) section of turbo.json define?
turbo.json tasks: each named task declares dependsOn (e.g. ["^build"] to build dependencies first), outputs (paths to cache like dist/**), and flags like cache and persistent. From this Turborepo builds a dependency graph to schedule and parallelise tasks across the monorepo.
2 / 5
What does the ^build syntax in dependsOn mean?
^ prefix:"dependsOn": ["^build"] tells Turborepo to run build in all of the package's dependencies (upstream in the graph) before building the package itself. Without the caret, a dependency refers to a task in the same package, allowing intra-package ordering like build depending on codegen.
3 / 5
How does Turborepo's caching avoid redundant work?
Content-based caching: Turborepo computes a hash from a task's source files, dependency graph, and declared environment variables. If a prior run with the same hash exists, it restores the recorded outputs and replays the logs immediately — a cache hit. This makes unchanged packages effectively free to rebuild.
4 / 5
What is Remote Caching in Turborepo?
Remote Caching: uploads task outputs to a shared store. When another developer or a CI job computes the same hash, it downloads the artefact rather than rebuilding. This shares work across the whole team and pipeline. It is configured with a remote cache provider and a team/token, dramatically cutting CI time.
5 / 5
Why should task outputs be declared accurately in turbo.json?
outputs: tells Turborepo which files a task produces (e.g. [".next/**", "!.next/cache/**"]). On a cache hit, only those paths are restored. If a build emits files not listed in outputs, they will be absent after a cache hit and downstream tasks may fail — so accurate output globs are essential for correct caching.