Turborepo
JetBrainsOfficialCreated by Anthony FuDistributed by JetBrains
- Skill
- Tool integration
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides comprehensive best practices and configuration patterns for Turborepo, the build system for JavaScript and TypeScript monorepos. It covers task pipeline orchestration, caching strategies, dependency management, and CI/CD integration to ensure efficient, parallelized builds across apps and packages.
What it does
- Defines task pipelines and dependency graphs in turbo.json
- Optimizes build performance through caching and remote cache configuration
- Enforces monorepo structure and architectural boundaries
- Provides patterns for CI/CD setup and incremental builds using --affected
- Guides proper dependency management and package-specific configuration
- Identifies and resolves common anti-patterns in task execution
When to use it
- Setting up a new monorepo or migrating existing projects
- Configuring task pipelines and build dependencies
- Troubleshooting cache misses or slow build performance
- Implementing CI/CD workflows for monorepos
- Structuring internal packages and sharing code between applications
Advantages
- Ensures optimal build performance via parallelization and caching
- Promotes clean, maintainable monorepo architecture
- Reduces build times by only processing affected packages
- Provides clear patterns for environment variable handling
- Standardizes configuration across diverse package types
Usage examples
- “How do I configure my turbo.json to build packages in the correct order?”
- The agent will explain the use of the dependsOn key with the ^ prefix to ensure dependencies are built before the consuming package.
- “My build is slow in CI. How can I only build what changed?”
- The agent will recommend using the --affected flag to identify and build only the packages impacted by recent git changes.
- “Where should I put my shared environment variables?”
- The agent will advise using globalEnv in turbo.json for shared variables or package-specific .env files for isolated configuration.
- “How do I fix a cache miss for my build task?”
- The agent will guide you through checking the outputs configuration, verifying environment variable inputs, and using --summarize to debug hash inputs.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/jetbrains/turborepo/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip turborepo.zip -d .agents/skills
Documentation by Anthony Fu
Turborepo Skill
Build system for JavaScript/TypeScript monorepos. Turborepo caches task outputs and runs tasks in parallel based on dependency graph.
IMPORTANT: Package Tasks, Not Root Tasks
DO NOT create Root Tasks. ALWAYS create package tasks.
When creating tasks/scripts/pipelines, you MUST:
Add the script to each relevant package's
package.jsonRegister the task in root
turbo.jsonRoot
package.jsononly delegates viaturbo run <task>
DO NOT put task logic in root package.json. This defeats Turborepo's parallelization.
// DO THIS: Scripts in each package
// apps/web/package.json
{ "scripts": { "build": "next build", "lint": "eslint .", "test": "vitest" } }
// apps/api/package.json
{ "scripts": { "build": "tsc", "lint": "eslint .", "test": "vitest" } }
// packages/ui/package.json
{ "scripts": { "build": "tsc", "lint": "eslint .", "test": "vitest" } }// turbo.json - register tasks
{
"tasks": {
"build": { "dependsOn": ["^build"], "outputs": ["dist/**"] },
"lint": {},
"test": { "dependsOn": ["build"] }
}
}// Root package.json - ONLY delegates, no task logic
{
"scripts": {
"build": "turbo run build",
"lint": "turbo run lint",
"test": "turbo run test"
}
}// DO NOT DO THIS - defeats parallelization
// Root package.json
{
"scripts": {
"build": "cd apps/web && next build && cd ../api && tsc",
"lint": "eslint apps/ packages/",
"test": "vitest"
}
}Root Tasks (//#taskname) are ONLY for tasks that truly cannot exist in packages (rare).
Secondary Rule: turbo run vs turbo
Always use turbo run when the command is written into code:
// package.json - ALWAYS "turbo run"
{
"scripts": {
"build": "turbo run build"
}
}# CI workflows - ALWAYS "turbo run"
- run: turbo run build --affectedThe shorthand turbo <tasks> is ONLY for one-off terminal commands typed directly by humans or agents. Never write turbo build into package.json, CI, or scripts.
Quick Decision Trees
"I need to configure a task"
Configure a task?
├─ Define task dependencies → references/configuration/tasks.md
├─ Lint/check-types (parallel + caching) → Use Transit Nodes pattern (see below)
├─ Specify build outputs → references/configuration/tasks.md#outputs
├─ Handle environment variables → references/environment/RULE.md
├─ Set up dev/watch tasks → references/configuration/tasks.md#persistent
├─ Package-specific config → references/configuration/RULE.md#package-configurations
└─ Global settings (cacheDir, daemon) → references/configuration/global-options.md"My cache isn't working"
Cache problems?
├─ Tasks run but outputs not restored → Missing `outputs` key
├─ Cache misses unexpectedly → references/caching/gotchas.md
├─ Need to debug hash inputs → Use --summarize or --dry
├─ Want to skip cache entirely → Use --force or cache: false
├─ Remote cache not working → references/caching/remote-cache.md
└─ Environment causing misses → references/environment/gotchas.md"I want to run only changed packages"
Run only what changed?
├─ Changed packages + dependents (RECOMMENDED) → turbo run build --affected
├─ Custom base branch → --affected --affected-base=origin/develop
├─ Manual git comparison → --filter=...[origin/main]
└─ See all filter options → references/filtering/RULE.md--affected is the primary way to run only changed packages. It automatically compares against the default branch and includes dependents.
"I want to filter packages"
Filter packages?
├─ Only changed packages → --affected (see above)
├─ By package name → --filter=web
├─ By directory → --filter=./apps/*
├─ Package + dependencies → --filter=web...
├─ Package + dependents → --filter=...web
└─ Complex combinations → references/filtering/patterns.md"Environment variables aren't working"
Environment issues?
├─ Vars not available at runtime → Strict mode filtering (default)
├─ Cache hits with wrong env → Var not in `env` key
├─ .env changes not causing rebuilds → .env not in `inputs`
├─ CI variables missing → references/environment/gotchas.md
└─ Framework vars (NEXT_PUBLIC_*) → Auto-included via inference"I need to set up CI"
CI setup?
├─ GitHub Actions → references/ci/github-actions.md
├─ Vercel deployment → references/ci/vercel.md
├─ Remote cache in CI → references/caching/remote-cache.md
├─ Only build changed packages → --affected flag
├─ Skip unnecessary builds → turbo-ignore (references/cli/commands.md)
└─ Skip container setup when no changes → turbo-ignore"I want to watch for changes during development"
Watch mode?
├─ Re-run tasks on change → turbo watch (references/watch/RULE.md)
├─ Dev servers with dependencies → Use `with` key (references/configuration/tasks.md#with)
├─ Restart dev server on dep change → Use `interruptible: true`
└─ Persistent dev tasks → Use `persistent: true`"I need to create/structure a package"
Package creation/structure?
├─ Create an internal package → references/best-practices/packages.md
├─ Repository structure → references/best-practices/structure.md
├─ Dependency management → references/best-practices/dependencies.md
├─ Best practices overview → references/best-practices/RULE.md
├─ JIT vs Compiled packages → references/best-practices/packages.md#compilation-strategies
└─ Sharing code between apps → references/best-practices/RULE.md#package-types"How should I structure my monorepo?"
Monorepo structure?
├─ Standard layout (apps/, packages/) → references/best-practices/RULE.md
├─ Package types (apps vs libraries) → references/best-practices/RULE.md#package-types
├─ Creating internal packages → references/best-practices/packages.md
├─ TypeScript configuration → references/best-practices/structure.md#typescript-configuration
├─ ESLint configuration → references/best-practices/structure.md#eslint-configuration
├─ Dependency management → references/best-practices/dependencies.md
└─ Enforce package boundaries → references/boundaries/RULE.md"I want to enforce architectural boundaries"
Enforce boundaries?
├─ Check for violations → turbo boundaries
├─ Tag packages → references/boundaries/RULE.md#tags
├─ Restrict which packages can import others → references/boundaries/RULE.md#rule-types
└─ Prevent cross-package file imports → references/boundaries/RULE.mdCritical Anti-Patterns
Using turbo Shorthand in Code
turbo run is recommended in package.json scripts and CI pipelines. The shorthand turbo <task> is intended for interactive terminal use.
// WRONG - using shorthand in package.json
{
"scripts": {
"build": "turbo build",
"dev": "turbo dev"
}
}
// CORRECT
{
"scripts": {
"build": "turbo run build",
"dev": "turbo run dev"
}
}# WRONG - using shorthand in CI
- run: turbo build --affected
# CORRECT
- run: turbo run build --affectedRoot Scripts Bypassing Turbo
Root package.json scripts MUST delegate to turbo run, not run tasks directly.
// WRONG - bypasses turbo entirely
{
"scripts": {
"build": "bun build",
"dev": "bun dev"
}
}
// CORRECT - delegates to turbo
{
"scripts": {
"build": "turbo run build",
"dev": "turbo run dev"
}
}Using && to Chain Turbo Tasks
Don't chain turbo tasks with &&. Let turbo orchestrate.
// WRONG - turbo task not using turbo run
{
"scripts": {
"changeset:publish": "bun build && changeset publish"
}
}
// CORRECT
{
"scripts": {
"changeset:publish": "turbo run build && changeset publish"
}
}prebuild Scripts That Manually Build Dependencies
Scripts like prebuild that manually build other packages bypass Turborepo's dependency graph.
// WRONG - manually building dependencies
{
"scripts": {
"prebuild": "cd ../../packages/types && bun run build && cd ../utils && bun run build",
"build": "next build"
}
}However, the fix depends on whether workspace dependencies are declared:
If dependencies ARE declared (e.g.,
"@repo/types": "workspace:*"in package.json), remove theprebuildscript. Turbo'sdependsOn: ["^build"]handles this automatically.If dependencies are NOT declared, the
prebuildexists because^buildwon't trigger without a dependency relationship. The fix is to:Add the dependency to package.json:
"@repo/types": "workspace:*"Then remove the
prebuildscript
// CORRECT - declare dependency, let turbo handle build order
// package.json
{
"dependencies": {
"@repo/types": "workspace:*",
"@repo/utils": "workspace:*"
},
"scripts": {
"build": "next build"
}
}
// turbo.json
{
"tasks": {
"build": {
"dependsOn": ["^build"]
}
}
}Key insight: ^build only runs build in packages listed as dependencies. No dependency declaration = no automatic build ordering.
Overly Broad globalDependencies
globalDependencies affects ALL tasks in ALL packages. Be specific.
// WRONG - heavy hammer, affects all hashes
{
"globalDependencies": ["**/.env.*local"]
}
// BETTER - move to task-level inputs
{
"globalDependencies": [".env"],
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", ".env*"],
"outputs": ["dist/**"]
}
}
}Repetitive Task Configuration
Look for repeated configuration across tasks that can be collapsed. Turborepo supports shared configuration patterns.
// WRONG - repetitive env and inputs across tasks
{
"tasks": {
"build": {
"env": ["API_URL", "DATABASE_URL"],
"inputs": ["$TURBO_DEFAULT$", ".env*"]
},
"test": {
"env": ["API_URL", "DATABASE_URL"],
"inputs": ["$TURBO_DEFAULT$", ".env*"]
},
"dev": {
"env": ["API_URL", "DATABASE_URL"],
"inputs": ["$TURBO_DEFAULT$", ".env*"],
"cache": false,
"persistent": true
}
}
}
// BETTER - use globalEnv and globalDependencies for shared config
{
"globalEnv": ["API_URL", "DATABASE_URL"],
"globalDependencies": [".env*"],
"tasks": {
"build": {},
"test": {},
"dev": {
"cache": false,
"persistent": true
}
}
}When to use global vs task-level:
globalEnv/globalDependencies- affects ALL tasks, use for truly shared configTask-level
env/inputs- use when only specific tasks need it
NOT an Anti-Pattern: Large env Arrays
A large env array (even 50+ variables) is not a problem. It usually means the user was thorough about declaring their build's environment dependencies. Do not flag this as an issue.
Using --parallel Flag
The --parallel flag bypasses Turborepo's dependency graph. If tasks need parallel execution, configure dependsOn correctly instead.
# WRONG - bypasses dependency graph
turbo run lint --parallel
# CORRECT - configure tasks to allow parallel execution
# In turbo.json, set dependsOn appropriately (or use transit nodes)
turbo run lintPackage-Specific Task Overrides in Root turbo.json
When multiple packages need different task configurations, use Package Configurations (turbo.json in each package) instead of cluttering root turbo.json with package#task overrides.
// WRONG - root turbo.json with many package-specific overrides
{
"tasks": {
"test": { "dependsOn": ["build"] },
"@repo/web#test": { "outputs": ["coverage/**"] },
"@repo/api#test": { "outputs": ["coverage/**"] },
"@repo/utils#test": { "outputs": [] },
"@repo/cli#test": { "outputs": [] },
"@repo/core#test": { "outputs": [] }
}
}
// CORRECT - use Package Configurations
// Root turbo.json - base config only
{
"tasks": {
"test": { "dependsOn": ["build"] }
}
}
// packages/web/turbo.json - package-specific override
{
"extends": ["//"],
"tasks": {
"test": { "outputs": ["coverage/**"] }
}
}
// packages/api/turbo.json
{
"extends": ["//"],
"tasks": {
"test": { "outputs": ["coverage/**"] }
}
}Benefits of Package Configurations:
Keeps configuration close to the code it affects
Root turbo.json stays clean and focused on base patterns
Easier to understand what's special about each package
Works with
$TURBO_EXTENDS$to inherit + extend arrays
When to use package#task in root:
Single package needs a unique dependency (e.g.,
"deploy": { "dependsOn": ["web#build"] })Temporary override while migrating
See references/configuration/RULE.md#package-configurations for full details.
Using ../ to Traverse Out of Package in inputs
Don't use relative paths like ../ to reference files outside the package. Use $TURBO_ROOT$ instead.
// WRONG - traversing out of package
{
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", "../shared-config.json"]
}
}
}
// CORRECT - use $TURBO_ROOT$ for repo root
{
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/shared-config.json"]
}
}
}Missing outputs for File-Producing Tasks
Before flagging missing outputs, check what the task actually produces:
Read the package's script (e.g.,
"build": "tsc","test": "vitest")Determine if it writes files to disk or only outputs to stdout
Only flag if the task produces files that should be cached
// WRONG: build produces files but they're not cached
{
"tasks": {
"build": {
"dependsOn": ["^build"]
}
}
}
// CORRECT: build outputs are cached
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"]
}
}
}Common outputs by framework:
Next.js:
[".next/**", "!.next/cache/**"]Vite/Rollup:
["dist/**"]tsc:
["dist/**"]or customoutDir
TypeScript --noEmit can still produce cache files:
When incremental: true in tsconfig.json, tsc --noEmit writes .tsbuildinfo files even without emitting JS. Check the tsconfig before assuming no outputs:
// If tsconfig has incremental: true, tsc --noEmit produces cache files
{
"tasks": {
"typecheck": {
"outputs": ["node_modules/.cache/tsbuildinfo.json"] // or wherever tsBuildInfoFile points
}
}
}To determine correct outputs for TypeScript tasks:
Check if
incrementalorcompositeis enabled in tsconfigCheck
tsBuildInfoFilefor custom cache location (default: alongsideoutDiror in project root)If no incremental mode,
tsc --noEmitproduces no files
^build vs build Confusion
{
"tasks": {
// ^build = run build in DEPENDENCIES first (other packages this one imports)
"build": {
"dependsOn": ["^build"]
},
// build (no ^) = run build in SAME PACKAGE first
"test": {
"dependsOn": ["build"]
},
// pkg#task = specific package's task
"deploy": {
"dependsOn": ["web#build"]
}
}
}Environment Variables Not Hashed
// WRONG: API_URL changes won't cause rebuilds
{
"tasks": {
"build": {
"outputs": ["dist/**"]
}
}
}
// CORRECT: API_URL changes invalidate cache
{
"tasks": {
"build": {
"outputs": ["dist/**"],
"env": ["API_URL", "API_KEY"]
}
}
}.env Files Not in Inputs
Turbo does NOT load .env files - your framework does. But Turbo needs to know about changes:
// WRONG: .env changes don't invalidate cache
{
"tasks": {
"build": {
"env": ["API_URL"]
}
}
}
// CORRECT: .env file changes invalidate cache
{
"tasks": {
"build": {
"env": ["API_URL"],
"inputs": ["$TURBO_DEFAULT$", ".env", ".env.*"]
}
}
}Root .env File in Monorepo
A .env file at the repo root is an anti-pattern — even for small monorepos or starter templates. It creates implicit coupling between packages and makes it unclear which packages depend on which variables.
// WRONG - root .env affects all packages implicitly
my-monorepo/
├── .env # Which packages use this?
├── apps/
│ ├── web/
│ └── api/
└── packages/
// CORRECT - .env files in packages that need them
my-monorepo/
├── apps/
│ ├── web/
│ │ └── .env # Clear: web needs DATABASE_URL
│ └── api/
│ └── .env # Clear: api needs API_KEY
└── packages/Problems with root .env:
Unclear which packages consume which variables
All packages get all variables (even ones they don't need)
Cache invalidation is coarse-grained (root .env change invalidates everything)
Security risk: packages may accidentally access sensitive vars meant for others
Bad habits start small — starter templates should model correct patterns
If you must share variables, use globalEnv to be explicit about what's shared, and document why.
Strict Mode Filtering CI Variables
By default, Turborepo filters environment variables to only those in env/globalEnv. CI variables may be missing:
// If CI scripts need GITHUB_TOKEN but it's not in env:
{
"globalPassThroughEnv": ["GITHUB_TOKEN", "CI"],
"tasks": { ... }
}Or use --env-mode=loose (not recommended for production).
Shared Code in Apps (Should Be a Package)
// WRONG: Shared code inside an app
apps/
web/
shared/ # This breaks monorepo principles!
utils.ts
// CORRECT: Extract to a package
packages/
utils/
src/utils.tsAccessing Files Across Package Boundaries
// WRONG: Reaching into another package's internals
import { Button } from "../../packages/ui/src/button";
// CORRECT: Install and import properly
import { Button } from "@repo/ui/button";Too Many Root Dependencies
// WRONG: App dependencies in root
{
"dependencies": {
"react": "^18",
"next": "^14"
}
}
// CORRECT: Only repo tools in root
{
"devDependencies": {
"turbo": "latest"
}
}Common Task Configurations
Standard Build Pipeline
{
"$schema": "https://v2-8-18-canary-7.turborepo.dev/schema.json",
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", ".next/**", "!.next/cache/**"]
},
"dev": {
"cache": false,
"persistent": true
}
}
}Add a transit task if you have tasks that need parallel execution with cache invalidation (see below).
Dev Task with ^dev Pattern (for turbo watch)
A dev task with dependsOn: ["^dev"] and persistent: false in root turbo.json may look unusual but is correct for turbo watch workflows:
// Root turbo.json
{
"tasks": {
"dev": {
"dependsOn": ["^dev"],
"cache": false,
"persistent": false // Packages have one-shot dev scripts
}
}
}
// Package turbo.json (apps/web/turbo.json)
{
"extends": ["//"],
"tasks": {
"dev": {
"persistent": true // Apps run long-running dev servers
}
}
}Why this works:
Packages (e.g.,
@acme/db,@acme/validators) have"dev": "tsc"— one-shot type generation that completes quicklyApps override with
persistent: truefor actual dev servers (Next.js, etc.)turbo watchre-runs the one-shot packagedevscripts when source files change, keeping types in sync
Intended usage: Run turbo watch dev (not turbo run dev). Watch mode re-executes one-shot tasks on file changes while keeping persistent tasks running.
Alternative pattern: Use a separate task name like prepare or generate for one-shot dependency builds to make the intent clearer:
{
"tasks": {
"prepare": {
"dependsOn": ["^prepare"],
"outputs": ["dist/**"]
},
"dev": {
"dependsOn": ["prepare"],
"cache": false,
"persistent": true
}
}
}Transit Nodes for Parallel Tasks with Cache Invalidation
Some tasks can run in parallel (don't need built output from dependencies) but must invalidate cache when dependency source code changes.
The problem with dependsOn: ["^taskname"]:
Forces sequential execution (slow)
The problem with dependsOn: [] (no dependencies):
Allows parallel execution (fast)
But cache is INCORRECT - changing dependency source won't invalidate cache
Transit Nodes solve both:
{
"tasks": {
"transit": { "dependsOn": ["^transit"] },
"my-task": { "dependsOn": ["transit"] }
}
}The transit task creates dependency relationships without matching any actual script, so tasks run in parallel with correct cache invalidation.
How to identify tasks that need this pattern: Look for tasks that read source files from dependencies but don't need their build outputs.
With Environment Variables
{
"globalEnv": ["NODE_ENV"],
"globalDependencies": [".env"],
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"],
"env": ["API_URL", "DATABASE_URL"]
}
}
}Reference Index
Configuration
| File | Purpose |
|---|---|
| configuration/RULE.md | turbo.json overview, Package Configurations |
| configuration/tasks.md | dependsOn, outputs, inputs, env, cache, persistent |
| configuration/global-options.md | globalEnv, globalDependencies, cacheDir, daemon, envMode |
| configuration/gotchas.md | Common configuration mistakes |
Caching
| File | Purpose |
|---|---|
| caching/RULE.md | How caching works, hash inputs |
| caching/remote-cache.md | Vercel Remote Cache, self-hosted, login/link |
| caching/gotchas.md | Debugging cache misses, --summarize, --dry |
Environment Variables
| File | Purpose |
|---|---|
| environment/RULE.md | env, globalEnv, passThroughEnv |
| environment/modes.md | Strict vs Loose mode, framework inference |
| environment/gotchas.md | .env files, CI issues |
Filtering
| File | Purpose |
|---|---|
| filtering/RULE.md | --filter syntax overview |
| filtering/patterns.md | Common filter patterns |
CI/CD
| File | Purpose |
|---|---|
| ci/RULE.md | General CI principles |
| ci/github-actions.md | Complete GitHub Actions setup |
| ci/vercel.md | Vercel deployment, turbo-ignore |
| ci/patterns.md | --affected, caching strategies |
CLI
| File | Purpose |
|---|---|
| cli/RULE.md | turbo run basics |
| cli/commands.md | turbo run flags, turbo-ignore, other commands |
Best Practices
| File | Purpose |
|---|---|
| best-practices/RULE.md | Monorepo best practices overview |
| best-practices/structure.md | Repository structure, workspace config, TypeScript/ESLint setup |
| best-practices/packages.md | Creating internal packages, JIT vs Compiled, exports |
| best-practices/dependencies.md | Dependency management, installing, version sync |
Watch Mode
| File | Purpose |
|---|---|
| watch/RULE.md | turbo watch, interruptible tasks, dev workflows |
Boundaries (Experimental)
| File | Purpose |
|---|---|
| boundaries/RULE.md | Enforce package isolation, tag-based dependency rules |
Source Documentation
This skill is based on the official Turborepo documentation at:
Source:
apps/docs/content/docs/in the Turborepo repository
Files
- ATTRIBUTION.mdAdded by AutoGineer885 B
- LICENSE.md1.0 KiB
- SKILL.md26.7 KiB
- SYNC.md146 B
- command/turborepo.md2.5 KiB
- references/best-practices/RULE.md4.8 KiB
- references/best-practices/dependencies.md4.2 KiB
- references/best-practices/packages.md6.1 KiB
- references/best-practices/structure.md4.8 KiB
- references/boundaries/RULE.md1.9 KiB
- references/caching/RULE.md2.2 KiB
- references/caching/gotchas.md2.8 KiB
- references/caching/remote-cache.md2.5 KiB
- references/ci/RULE.md2.1 KiB
- references/ci/github-actions.md2.7 KiB
- references/ci/patterns.md2.5 KiB
- references/ci/vercel.md2.1 KiB
- references/cli/RULE.md2.1 KiB
- references/cli/commands.md5.4 KiB
- references/configuration/RULE.md4.2 KiB
- references/configuration/global-options.md4.4 KiB
- references/configuration/gotchas.md7.9 KiB
- references/configuration/tasks.md5.3 KiB
- references/environment/RULE.md1.7 KiB
- references/environment/gotchas.md2.9 KiB
- references/environment/modes.md2.4 KiB
- references/filtering/RULE.md4.1 KiB
- references/filtering/patterns.md2.4 KiB
- references/watch/RULE.md1.9 KiB
references/cli/commands.md
turbo run Flags Reference
Full docs: https://turborepo.dev/docs/reference/run
Package Selection
--filter / -F
Select specific packages to run tasks in.
turbo build --filter=web
turbo build -F=@repo/ui -F=@repo/utils
turbo test --filter=./apps/*See filtering/ for complete syntax (globs, dependencies, git ranges).
Task Identifier Syntax (v2.2.4+)
Run specific package tasks directly:
turbo run web#build # Build web package
turbo run web#build docs#lint # Multiple specific tasks--affected
Run only in packages changed since the base branch.
turbo build --affected
turbo test --affected --filter=./apps/* # combine with filterHow it works:
Default: compares
main...HEADIn GitHub Actions: auto-detects
GITHUB_BASE_REFOverride base:
TURBO_SCM_BASE=development turbo build --affectedOverride head:
TURBO_SCM_HEAD=your-branch turbo build --affected
Requires git history - shallow clones may fall back to running all tasks.
Execution Control
--dry / --dry=json
Preview what would run without executing.
turbo build --dry # human-readable
turbo build --dry=json # machine-readable--force
Ignore all cached artifacts, re-run everything.
turbo build --force--concurrency
Limit parallel task execution.
turbo build --concurrency=4 # max 4 tasks
turbo build --concurrency=50% # 50% of CPU cores--continue
Keep running other tasks when one fails.
turbo build test --continue--only
Run only the specified task, skip its dependencies.
turbo build --only # skip running dependsOn tasks--parallel (Discouraged)
Ignores task graph dependencies, runs all tasks simultaneously. Avoid using this flag—if tasks need to run in parallel, configure dependsOn correctly instead. Using --parallel bypasses Turborepo's dependency graph, which can cause race conditions and incorrect builds.
Cache Control
--cache
Fine-grained cache behavior control.
# Default: read/write both local and remote
turbo build --cache=local:rw,remote:rw
# Read-only local, no remote
turbo build --cache=local:r,remote:
# Disable local, read-only remote
turbo build --cache=local:,remote:r
# Disable all caching
turbo build --cache=local:,remote:Output & Debugging
--graph
Generate task graph visualization.
turbo build --graph # opens in browser
turbo build --graph=graph.svg # SVG file
turbo build --graph=graph.png # PNG file
turbo build --graph=graph.json # JSON data
turbo build --graph=graph.mermaid # Mermaid diagram--summarize
Generate JSON run summary for debugging.
turbo build --summarize
# creates .turbo/runs/<run-id>.json--output-logs
Control log output verbosity.
turbo build --output-logs=full # all logs (default)
turbo build --output-logs=new-only # only cache misses
turbo build --output-logs=errors-only # only failures
turbo build --output-logs=none # silent--profile
Generate Chrome tracing profile for performance analysis.
turbo build --profile=profile.json
# open chrome://tracing and load the file--verbosity / -v
Control turbo's own log level.
turbo build -v # verbose
turbo build -vv # more verbose
turbo build -vvv # maximum verbosityEnvironment
--env-mode
Control environment variable handling.
turbo build --env-mode=strict # only declared env vars (default)
turbo build --env-mode=loose # include all env vars in hashUI
--ui
Select output interface.
turbo build --ui=tui # interactive terminal UI (default in TTY)
turbo build --ui=stream # streaming logs (default in CI)turbo-ignore
Full docs: https://turborepo.dev/docs/reference/turbo-ignore
Skip CI work when nothing relevant changed. Useful for skipping container setup.
Basic Usage
# Check if build is needed for current package (uses Automatic Package Scoping)
npx turbo-ignore
# Check specific package
npx turbo-ignore web
# Check specific task
npx turbo-ignore --task=testExit Codes
0: No changes detected - skip CI work1: Changes detected - proceed with CI
CI Integration Example
# GitHub Actions
- name: Check for changes
id: turbo-ignore
run: npx turbo-ignore web
continue-on-error: true
- name: Build
if: steps.turbo-ignore.outcome == 'failure' # changes detected
run: pnpm buildComparison Depth
Default: compares to parent commit (HEAD^1).
# Compare to specific commit
npx turbo-ignore --fallback=abc123
# Compare to branch
npx turbo-ignore --fallback=mainOther Commands
turbo boundaries
Check workspace violations (experimental).
turbo boundariesSee references/boundaries/ for configuration.
turbo watch
Re-run tasks on file changes.
turbo watch build testSee references/watch/ for details.
turbo prune
Create sparse checkout for Docker.
turbo prune web --dockerturbo link / unlink
Connect/disconnect Remote Cache.
turbo link # connect to Vercel Remote Cache
turbo unlink # disconnectturbo login / logout
Authenticate with Remote Cache provider.
turbo login # authenticate
turbo logout # log outturbo generate
Scaffold new packages.
turbo generateRequirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an API key
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Anthony Fu
- Publisher
- JetBrains (Official)
- Distributed by
- JetBrains
- Source
- JetBrains/skills · turborepo · commit 3f53782
- Licence
- MIT License (redistribution allowed)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthony Fu or JetBrains.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download turborepo.zip