Turborepo
Turborepo Configuration
Configuration options when using DxCore with Turborepo.
Adapter Capabilities
The Turborepo adapter provides the richest integration. The --dry=json output includes:
| Field | Available | Description |
|---|---|---|
| Task ID | Yes | Unique identifier for each task |
| Package name | Yes | Which workspace package the task belongs to |
| Dependencies | Yes | Full dependency edges between tasks |
| Task hash | Yes | Content hash for cache identification |
| Cache status | Yes | Whether the task has a cache hit |
| Command | Yes | The actual command that will be executed |
Build System Flag
Always pass -b turbo to both the dispatcher and agent commands:
# Dispatcher
turbo run build test --dry=json | dxcore dispatch \
-c $URL -s $SESSION -t $TOKEN -b turbo
# Agent
dxcore agent \
-c $URL -a agent-1 -s $SESSION -t $TOKEN -b turbo
Working Directory
Use --work-dir (or -w) if your Turborepo root is not the repository root:
turbo run build --dry=json | dxcore dispatch \
-c $URL -s $SESSION -t $TOKEN -b turbo -w ./packages/monorepo
Agents also accept -w — it sets the directory where npx turbo run ... is executed.
Cache Behavior
DxCore does not provide its own caching. Caching is handled by external systems — Turbo Remote Cache, Nx cache, Docker BuildKit cache. DxCore relies on these outside systems entirely.
When turbo run --dry=json reports a task as a cache hit, the coordinator marks it as :done immediately during scheduling (Scheduler.init/1) — the task never enters the work frontier and is never assigned to an agent. Cached tasks complete instantly without consuming agent resources.
Tip
Because cache-hit tasks are skipped at the scheduling level, they do not occupy agent slots. If most of your tasks are cache hits, fewer agents are needed for a given run.
Sharding Tasks
Place a dxcore.json file in any package directory to shard specific tasks:
apps/web/dxcore.json → shards web's test task
packages/core/dxcore.json → shards core's test task
See Shard Configuration for the file format.