turborepo
Turborepoを使ったモノレポのビルドシステムに関するガイダンスを提供します。`turbo.json`のタスクパイプライン設定、`dependsOn`やキャッシュ・リモートキャッシュの最適化、`--filter`・`--affected`を使った差分ビルド、CI最適化、内部パッケージの共有など、モノレポの構築・運用全般に関する操作や質問に対して機能します。
description の原文を見る
| Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.
SKILL.md 本文
Turborepo スキル
JavaScript/TypeScript monorepo向けのビルドシステム。Turborepoはタスク出力をキャッシュし、依存関係グラフに基づいてタスクを並列実行します。
重要: ルートタスクではなくパッケージタスク
ルートタスクよりパッケージタスクを優先してください。
タスク/スクリプト/パイプラインを作成するときは、パッケージタスクをデフォルトにする必要があります:
- 各関連パッケージの
package.jsonにスクリプトを追加 - ルート
turbo.jsonでタスクを登録 - ルート
package.jsonはturbo run <task>で委譲するのみ
タスクロジックをパッケージに配置できる場合、ルート package.json に配置しないでください。 これはTurborepoの並列化を無効にします。
// これをしてください: 各パッケージのスクリプト
// 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 - タスクを登録
{
"tasks": {
"build": { "dependsOn": ["^build"], "outputs": ["dist/**"] },
"lint": {},
"test": { "dependsOn": ["build"] }
}
}
// ルート package.json - 委譲のみで、タスクロジックなし
{
"scripts": {
"build": "turbo run build",
"lint": "turbo run lint",
"test": "turbo run test"
}
}
// これをしないでください - 並列化を無効にします
// ルート package.json
{
"scripts": {
"build": "cd apps/web && next build && cd ../api && tsc",
"lint": "eslint apps/ packages/",
"test": "vitest"
}
}
ルートタスク (//#taskname) は、Vitest Projects の //#test、リポジトリ全体のリリーススクリプト、または turbo 自体を呼び出さないツーリングなど、パッケージに存在できない真のタスクのみです。
二番目のルール: turbo run vs turbo
コードに書き込まれるコマンドの場合は常に turbo run を使用してください:
// package.json - 常に "turbo run"
{
"scripts": {
"build": "turbo run build"
}
}
# CI ワークフロー - 常に "turbo run"
- run: turbo run build --affected
短縮形 turbo <tasks> は一度限りの端末コマンドのみです で、人またはエージェントが直接タイプします。package.json、CI、スクリプトに turbo build を書き込まないでください。
クイック決定ツリー
「タスクを設定する必要があります」
タスクを設定しますか?
├─ タスク依存関係を定義 → references/configuration/tasks.md
├─ Lint/型チェック (並列+キャッシング) → Transit Nodes パターンを使用 (下記参照)
├─ ビルド出力を指定 → references/configuration/tasks.md#outputs
├─ 環境変数を処理 → references/environment/RULE.md
├─ dev/watchタスクをセットアップ → references/configuration/tasks.md#persistent
├─ パッケージ固有の設定 → references/configuration/RULE.md#package-configurations
└─ グローバル設定 (cacheDir, daemon) → references/configuration/global-options.md
「キャッシュが機能していない」
キャッシュの問題?
├─ タスクは実行されるが出力が復元されない → `outputs` キーが不足している
├─ キャッシュミスが予期しない → references/caching/gotchas.md
├─ ハッシュ入力をデバッグしたい → --summarize または --dry を使用
├─ キャッシュをスキップしたい → --force または cache: false を使用
├─ リモートキャッシュが機能していない → references/caching/remote-cache.md
└─ 環境がミスの原因 → references/environment/gotchas.md
「変更されたパッケージのみを実行したい」
変更されたパッケージのみを実行しますか?
├─ 変更されたパッケージ + 依存元 (推奨) → turbo run build --affected
├─ カスタムベースブランチ → --affected --affected-base=origin/develop
├─ 手動git比較 → --filter=...[origin/main]
└─ すべてのフィルターオプションを参照 → references/filtering/RULE.md
--affected は、変更されたパッケージのみを実行するための主な方法です。 デフォルトブランチと自動的に比較し、依存元を含めます。
「パッケージをフィルター処理したい」
パッケージをフィルター処理しますか?
├─ 変更されたパッケージのみ → --affected (上記参照)
├─ パッケージ名で → --filter=web
├─ ディレクトリで → --filter=./apps/*
├─ パッケージ + 依存関係 → --filter=web...
├─ パッケージ + 依存元 → --filter=...web
└─ 複雑な組み合わせ → references/filtering/patterns.md
「環境変数が機能していない」
環境問題?
├─ 変数が実行時に利用できない → Strict mode フィルタリング (デフォルト)
├─ 間違った環境でキャッシュヒット → 変数が `env` キーにない
├─ .env 変更がリビルドを引き起こさない → .env が `inputs` にない
├─ CI 変数が不足している → references/environment/gotchas.md
└─ フレームワーク変数 (NEXT_PUBLIC_*) → 推論を介して自動含有
「CI を設定する必要があります」
CI セットアップ?
├─ GitHub Actions → references/ci/github-actions.md
├─ Vercel デプロイ → references/ci/vercel.md
├─ CI でのリモートキャッシュ → references/caching/remote-cache.md
├─ 変更されたパッケージのみをビルド → --affected フラグ
├─ 不要なビルドをスキップ → turbo-ignore (references/cli/commands.md)
└─ 変更がない場合はコンテナセットアップをスキップ → turbo-ignore
「開発中に変更を監視したい」
Watch モード?
├─ 変更時にタスクを再実行 → turbo watch (references/watch/RULE.md)
├─ 依存関係を持つ dev サーバー → `with` キーを使用 (references/configuration/tasks.md#with)
├─ 依存関係の変更時に dev サーバーを再起動 → `interruptible: true` を使用
└─ 永続的な dev タスク → `persistent: true` を使用
「パッケージを作成/構造化する必要があります」
パッケージの作成/構造化?
├─ 内部パッケージを作成 → references/best-practices/packages.md
├─ リポジトリ構造 → references/best-practices/structure.md
├─ 依存関係管理 → references/best-practices/dependencies.md
├─ ベストプラクティス概要 → references/best-practices/RULE.md
├─ JIT vs コンパイル済みパッケージ → references/best-practices/packages.md#compilation-strategies
└─ アプリ間でコードを共有 → references/best-practices/RULE.md#package-types
「monorepo をどのように構造化すべきですか?」
Monorepo の構造?
├─ 標準的なレイアウト (apps/, packages/) → references/best-practices/RULE.md
├─ パッケージタイプ (アプリ vs ライブラリ) → references/best-practices/RULE.md#package-types
├─ 内部パッケージを作成 → references/best-practices/packages.md
├─ TypeScript 設定 → references/best-practices/structure.md#typescript-configuration
├─ ESLint 設定 → references/best-practices/structure.md#eslint-configuration
├─ 依存関係管理 → references/best-practices/dependencies.md
└─ パッケージの境界を強制 → references/boundaries/RULE.md
「アーキテクチャの境界を強制したい」
境界を強制しますか?
├─ 違反を確認 → turbo boundaries
├─ パッケージにタグを付ける → references/boundaries/RULE.md#tags
├─ どのパッケージが他をインポートできるかを制限 → references/boundaries/RULE.md#rule-types
└─ パッケージ間のファイルインポートを防止 → references/boundaries/RULE.md
重大なアンチパターン
コード内での turbo 短縮形の使用
turbo run は package.json スクリプトと CI パイプラインで推奨されます。 短縮形 turbo <task> は対話的なターミナル用です。
// 間違い - package.json で短縮形を使用
{
"scripts": {
"build": "turbo build",
"dev": "turbo dev"
}
}
// 正しい
{
"scripts": {
"build": "turbo run build",
"dev": "turbo run dev"
}
}
# 間違い - CI で短縮形を使用
- run: turbo build --affected
# 正しい
- run: turbo run build --affected
Turbo をバイパスするルートスクリプト
ルート package.json スクリプトは turbo run に委譲する必要があり、タスクを直接実行しません。
// 間違い - turbo をバイパス
{
"scripts": {
"build": "bun build",
"dev": "bun dev"
}
}
// 正しい - turbo に委譲
{
"scripts": {
"build": "turbo run build",
"dev": "turbo run dev"
}
}
&& を使用した Turbo タスクの連結
turbo タスクを && で連結しないでください。turbo にオーケストレーションさせてください。
// 間違い - turbo タスクが turbo run を使用していない
{
"scripts": {
"changeset:publish": "bun build && changeset publish"
}
}
// 正しい
{
"scripts": {
"changeset:publish": "turbo run build && changeset publish"
}
}
手動で依存関係をビルドする prebuild スクリプト
prebuild などのスクリプトが他のパッケージを手動でビルドする場合、Turborepo の依存関係グラフをバイパスします。
// 間違い - 依存関係を手動でビルド
{
"scripts": {
"prebuild": "cd ../../packages/types && bun run build && cd ../utils && bun run build",
"build": "next build"
}
}
しかし、修正方法はワークスペース依存関係が宣言されているかに依存します:
-
依存関係が宣言されている場合 (例、package.json の
"@repo/types": "workspace:*")、prebuildスクリプトを削除します。Turbo のdependsOn: ["^build"]がこれを自動的に処理します。 -
依存関係が宣言されていない場合、
prebuildは依存関係なしで^buildがトリガーされないため存在します。修正は:- package.json に依存関係を追加:
"@repo/types": "workspace:*" - その後
prebuildスクリプトを削除
- package.json に依存関係を追加:
// 正しい - 依存関係を宣言し、turbo にビルド順序を処理させる
// package.json
{
"dependencies": {
"@repo/types": "workspace:*",
"@repo/utils": "workspace:*"
},
"scripts": {
"build": "next build"
}
}
// turbo.json
{
"tasks": {
"build": {
"dependsOn": ["^build"]
}
}
}
重要な洞察: ^build は依存関係として列挙されたパッケージのビルドのみを実行します。依存関係宣言なし = 自動ビルド順序なし。
過度に広い globalDependencies
globalDependencies はグローバルハッシュを通じて ALL パッケージの ALL タスクに影響します — タスクは inputs 内の否定グロブでさえ特定ファイルをオプトアウトできません。具体的にしてください。
// 間違い - 重いハンマー、すべてのハッシュに影響
{
"globalDependencies": ["**/.env.*local"]
}
// より良い - タスク レベルの inputs に移行
{
"globalDependencies": [".env"],
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", ".env*"],
"outputs": ["dist/**"]
}
}
}
futureFlags.globalConfiguration を使用する場合、global.inputs ファイルは各タスクの inputs に折りたたまれ (グローバルハッシュではなく)、タスクは特定ファイルを除外できるため、この問題は軽減されます:
// ベスト - global.inputs とタスク別除外
{
"futureFlags": { "globalConfiguration": true },
"global": {
"inputs": [".env"]
},
"tasks": {
"build": { "outputs": ["dist/**"] },
"lint": {
"inputs": ["$TURBO_DEFAULT$", "!$TURBO_ROOT$/.env"]
}
}
}
繰り返されるタスク設定
タスク間で繰り返される設定を探して、折りたたむことができるものを探してください。Turborepo は共有設定パターンをサポートしています。
// 間違い - タスク全体で繰り返される env と inputs
{
"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
}
}
}
// より良い - globalEnv と globalDependencies を使用して共有設定
{
"globalEnv": ["API_URL", "DATABASE_URL"],
"globalDependencies": [".env*"],
"tasks": {
"build": {},
"test": {},
"dev": {
"cache": false,
"persistent": true
}
}
}
グローバルとタスク レベルをいつ使用するか:
globalEnv/globalDependencies- すべてのタスクに影響、真に共有される設定に使用- タスク レベルの
env/inputs- 特定のタスクのみが必要な場合に使用
アンチパターンではありません: 大きな env 配列
大きな env 配列 (50+ 変数でも) は問題ではありません。 これは通常、ユーザーがビルドの環境依存を徹底的に宣言していることを意味します。これを問題としてフラグを立てないでください。
--parallel フラグの使用
--parallel フラグは Turborepo の依存関係グラフをバイパスします。タスクが並列実行を必要とする場合は、代わりに dependsOn を正しく設定してください。
# 間違い - 依存関係グラフをバイパス
turbo run lint --parallel
# 正しい - dependsOn を適切に設定してタスクを並列実行可能にする
# turbo.json では、dependsOn を適切に設定 (またはトランジット ノードを使用)
turbo run lint
ルート turbo.json でのパッケージ固有のタスク上書き
複数のパッケージが異なるタスク設定を必要とする場合、ルート turbo.json に package#task 上書きで詰め込む代わりに、パッケージ設定 (各パッケージの turbo.json) を使用してください。
// 間違い - 多くのパッケージ固有の上書きを含むルート turbo.json
{
"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": [] }
}
}
// 正しい - パッケージ設定を使用
// ルート turbo.json - 基本設定のみ
{
"tasks": {
"test": { "dependsOn": ["build"] }
}
}
// packages/web/turbo.json - パッケージ固有の上書き
{
"extends": ["//"],
"tasks": {
"test": { "outputs": ["coverage/**"] }
}
}
// packages/api/turbo.json
{
"extends": ["//"],
"tasks": {
"test": { "outputs": ["coverage/**"] }
}
}
パッケージ設定の利点:
- 設定を影響するコードの近くに保つ
- ルート turbo.json をクリーンで焦点に保つ
- 各パッケージの特殊な点を理解しやすい
$TURBO_EXTENDS$で配列の継承 + 拡張と動作
ルートで package#task を使用する場合:
- 単一パッケージが独自の依存関係を必要とする (例、
"deploy": { "dependsOn": ["web#build"] }) - マイグレーション中の一時的な上書き
詳細は references/configuration/RULE.md#package-configurations を参照してください。
inputs でパッケージから ../ を使用してトラバース
../ のような相対パスを使用してパッケージ外のファイルを参照しないでください。代わりに $TURBO_ROOT$ を使用してください。
// 間違い - パッケージから抜け出す
{
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", "../shared-config.json"]
}
}
}
// 正しい - リポジトリルートに $TURBO_ROOT$ を使用
{
"tasks": {
"build": {
"inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/shared-config.json"]
}
}
}
ファイル生成タスクの outputs がない
outputs がないことをフラグする前に、タスクが実際に何を生成するかを確認してください:
- パッケージのスクリプトを読む (例、
"build": "tsc"、"test": "vitest") - ディスクにファイルを書き込むか、stdout のみに出力するかを判断
- キャッシュすべき出力を生成する場合のみフラグします
// 間違い: ビルドがファイルを生成しますがキャッシュされていない
{
"tasks": {
"build": {
"dependsOn": ["^build"]
}
}
}
// 正しい: ビルド出力がキャッシュされている
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"]
}
}
}
フレームワーク別の一般的な outputs:
- Next.js:
[".next/**", "!.next/cache/**"] - Vite/Rollup:
["dist/**"] - tsc:
["dist/**"]またはカスタムoutDir
TypeScript --noEmit でもキャッシュファイルを生成できます:
tsconfig.json の incremental: true の場合、tsc --noEmit は JS を出力せずに .tsbuildinfo ファイルを書き込みます。出力がないと仮定する前に tsconfig を確認してください:
// tsconfig に incremental: true がある場合、tsc --noEmit はキャッシュファイルを生成
{
"tasks": {
"typecheck": {
"outputs": ["node_modules/.cache/tsbuildinfo.json"] // または tsBuildInfoFile が指す場所
}
}
}
TypeScript タスクの正しい outputs を決定するには:
- tsconfig で
incrementalまたはcompositeが有効になっているかを確認 tsBuildInfoFileでカスタムキャッシュ位置を確認 (デフォルト:outDirの隣またはプロジェクトルート)- incremental mode がない場合、
tsc --noEmitはファイルを生成しません
^build vs build の混乱
{
"tasks": {
// ^build = このパッケージがインポートする他のパッケージで最初にビルドを実行
"build": {
"dependsOn": ["^build"]
},
// build (^ なし) = 同じパッケージで最初にビルドを実行
"test": {
"dependsOn": ["build"]
},
// pkg#task = 特定パッケージのタスク
"deploy": {
"dependsOn": ["web#build"]
}
}
}
ハッシュされない環境変数
// 間違い: API_URL の変更はリビルドを引き起こさない
{
"tasks": {
"build": {
"outputs": ["dist/**"]
}
}
}
// 正しい: API_URL の変更はキャッシュを無効化
{
"tasks": {
"build": {
"outputs": ["dist/**"],
"env": ["API_URL", "API_KEY"]
}
}
}
inputs の .env ファイルがない
Turbo は .env ファイルをロードしません - フレームワークが行います。しかし Turbo は変更について知る必要があります:
// 間違い: .env の変更がキャッシュを無効化しない
{
"tasks": {
"build": {
"env": ["API_URL"]
}
}
}
// 正しい: .env ファイルの変更がキャッシュを無効化
{
"tasks": {
"build": {
"env": ["API_URL"],
"inputs": ["$TURBO_DEFAULT$", ".env", ".env.*"]
}
}
}
Monorepo のルート .env ファイル
リポジトリルートの .env ファイルはアンチパターンです — 小さな monorepo やスターターテンプレートであってもです。パッケージ間の暗黙的な結合を作成し、どのパッケージがどの変数に依存するか不明確になります。
// 間違い - ルート .env がすべてのパッケージに暗黙的に影響
my-monorepo/
├── .env # どのパッケージがこれを使用しますか?
├── apps/
│ ├── web/
│ └── api/
└── packages/
// 正しい - パッケージの .env ファイルが必要
my-monorepo/
├── apps/
│ ├── web/
│ │ └── .env # 明確: web は DATABASE_URL が必要
│ └── api/
│ └── .env # 明確: api は API_KEY が必要
└── packages/
ルート .env の問題:
- どのパッケージがどの変数を消費するか不明確
- すべてのパッケージがすべての変数を取得 (必要ない変数でも)
- キャッシュ無効化は粗粒度 (ルート .env の変更がすべてを無効化)
- セキュリティリスク: パッケージが他のパッケージ用の機密変数に意図せずアクセスする可能性
- 悪い習慣は小さく始まります — スターターテンプレートは正しいパターンをモデル化する必要があります
変数を共有する必要がある場合、globalEnv を使用して明確にし、理由をドキュメント化してください。
Strict Mode フィルタリング CI 変数
デフォルトでは、Turborepo は環境変数を env/globalEnv 内のみにフィルタリングします。CI 変数が不足する可能性があります:
// CI スクリプトが GITHUB_TOKEN が必要だがそれが env にない場合:
{
"globalPassThroughEnv": ["GITHUB_TOKEN", "CI"],
"tasks": { ... }
}
または --env-mode=loose を使用 (本番環境では非推奨)。
アプリ内の共有コード (パッケージである必要があります)
// 間違い: アプリ内の共有コード
apps/
web/
shared/ # これは monorepo の原則を破ります!
utils.ts
// 正しい: パッケージに抽出
packages/
utils/
src/utils.ts
パッケージ境界を超えたファイルへのアクセス
// 間違い: 別のパッケージの内部に到達
import { Button } from "../../packages/ui/src/button";
// 正しい: 適切にインストールしてインポート
import { Button } from "@repo/ui/button";
ルート依存関係が多すぎる
// 間違い: アプリ依存がルートに
{
"dependencies": {
"react": "^18",
"next": "^14"
}
}
// 正しい: リポジトリツールのみがルートに
{
"devDependencies": {
"turbo": "latest"
}
}
一般的なタスク設定
標準的なビルドパイプライン
{
"$schema": "https://v2-9-15-canary-1.turborepo.dev/schema.json",
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", ".next/**", "!.next/cache/**"]
},
"dev": {
"cache": false,
"persistent": true
}
}
}
キャッシュ無効化で並列実行が必要なタスクがある場合は、transit タスクを追加します (下記参照)。
^dev パターンを使用した Dev タスク (turbo watch の場合)
ルート turbo.json で dependsOn: ["^dev"] と persistent: false の dev タスクは奇妙に見えるかもしれませんが、turbo watch ワークフロー向けは正しいです:
// ルート turbo.json
{
"tasks": {
"dev": {
"dependsOn": ["^dev"],
"cache": false,
"persistent": false // パッケージは一度限りの dev スクリプト
}
}
}
// パッケージ turbo.json (apps/web/turbo.json)
{
"extends": ["//"],
"tasks": {
"dev": {
"persistent": true // アプリは長時間実行される dev サーバー
}
}
}
これが機能する理由:
- パッケージ (例、
@acme/db、@acme/validators) は"dev": "tsc"を持っています — 急速に完了する一度限りの型生成 - アプリ は
persistent: trueで上書き (Next.js など実際の dev サーバー) turbo watchソースファイルが変更されたときに、一度限りパッケージdevスクリプトを再実行し、型を同期状態に保ちながら、永続タスクの実行を継続
意図された使用法: turbo watch dev を実行 (turbo run dev ではなく)。Watch モードはファイル変更時に一度限りタスクを再実行し、永続タスクを実行し続けます。
代替パターン: 意図を明確にするために、一度限りの依存関係ビルドに prepare または generate などの別のタスク名を使用:
{
"tasks": {
"prepare": {
"dependsOn": ["^prepare"],
"outputs": ["dist/**"]
},
"dev": {
"dependsOn": ["prepare"],
"cache": false,
"persistent": true
}
}
}
キャッシュ無効化での並列タスクのトランジット ノード
いくつかのタスクは並列実行できます (依存関係から構築済み出力が必要ではありませんが、依存関係のソースコード変更時にキャッシュを無効化する必要があります。
dependsOn: ["^taskname"] の問題:
- 順序実行を強制 (遅い)
dependsOn: [] (依存関係なし) の問題:
- 並列実行を許可 (速い)
- しかし、キャッシュが間違っています - 依存関係ソース変更がキャッシュを無効化しません
トランジット ノードが解決:
{
"tasks": {
"transit": { "dependsOn": ["^transit"] },
"my-task": { "dependsOn": ["transit"] }
}
}
transit タスクは実際のスクリプトにマッチせずに依存関係を作成するため、タスクは正しいキャッシュ無効化で並列実行します。
このパターンが必要なタスクを識別する方法: 依存関係のソースファイルを読むがビルド出力を必要としないタスクを探してください。
環境変数付き
{
"globalEnv": ["NODE_ENV"],
"globalDependencies": [".env"],
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"],
"env": ["API_URL", "DATABASE_URL"]
}
}
}
futureFlags.globalConfiguration を使用する場合、同じ設定は global の下に移動します — .env はグローバルハッシュ入力ではなく、タスク別入力になります:
{
"futureFlags": { "globalConfiguration": true },
"global": {
"env": ["NODE_ENV"],
"inputs": [".env"]
},
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"],
"env": ["API_URL", "DATABASE_URL"]
}
}
}
リファレンスインデックス
設定
| ファイル | 目的 |
|---|---|
configuration/RULE.md | turbo.json 概要、パッケージ設定 |
configuration/tasks.md | dependsOn、outputs、inputs、env、cache、persistent |
configuration/global-options.md | globalEnv、globalDependencies、global キー、futureFlags、cacheDir、envMode |
configuration/gotchas.md | 一般的な設定の誤り |
キャッシング
| ファイル | 目的 |
|---|---|
caching/RULE.md | キャッシングの仕組み、ハッシュ入力 |
caching/remote-cache.md | Vercel Remote Cache、セルフホスト、ログイン/リンク |
caching/gotchas.md | キャッシュミスのデバッグ、--summarize、--dry |
環境変数
| ファイル | 目的 |
|---|---|
environment/RULE.md | env、globalEnv、passThroughEnv |
environment/modes.md | Strict vs Loose モード、フレームワーク推論 |
environment/gotchas.md | .env ファイル、CI の問題 |
フィルタリング
| ファイル | 目的 |
|---|---|
filtering/RULE.md | --filter 構文概要 |
filtering/patterns.md | 一般的なフィルターパターン |
CI/CD
| ファイル | 目的 |
|---|---|
ci/RULE.md | 一般的な CI 原則 |
ci/github-actions.md | 完全な GitHub Actions セットアップ |
ci/vercel.md | Vercel デプロイ、turbo-ignore |
ci/patterns.md | --affected、キャッシング戦略 |
CLI
| ファイル | 目的 |
|---|---|
cli/RULE.md | turbo run の基本 |
cli/commands.md | turbo run フラグ、turbo-ignore、その他のコマンド |
ベストプラクティス
| ファイル | 目的 |
|---|---|
best-practices/RULE.md | Monorepo ベストプラクティス概要 |
best-practices/structure.md | リポジトリ構造、ワークスペース設定、TypeScript/ESLint セットアップ |
best-practices/packages.md | 内部パッケージの作成、JIT vs コンパイル済み、exports |
best-practices/dependencies.md | 依存関係管理、インストール、バージョン同期 |
Watch モード
| ファイル | 目的 |
|---|---|
watch/RULE.md | turbo watch、interruptible タスク、dev ワークフロー |
境界 (実験的)
| ファイル | 目的 |
|---|---|
boundaries/RULE.md | パッケージ分離の強制、タグベースの依存関係ルール |
ソースドキュメント
このスキルは以下のオフィシャル Turborepo ドキュメントに基づいています:
- ソース: Turborepo リポジトリの
apps/docs/content/docs/ - ライブ: https://turborepo.dev/docs
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- vercel
- リポジトリ
- vercel/turborepo
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/vercel/turborepo / ライセンス: MIT
関連スキル
superpowers-streamer-cli
SuperPowers デスクトップストリーマーの npm パッケージをインストール、ログイン、実行、トラブルシューティングできます。ユーザーが npm から `superpowers-ai` をセットアップしたい場合、メールまたは電話でサインインもしくはアカウント作成を行いたい場合、ストリーマーを起動したい場合、表示されたコントロールリンクを開きたい場合、後で停止したい場合、またはソースコードへのアクセスなしに npm やランタイムの一般的な問題から復旧したい場合に使用します。
catc-client-ops
Catalyst Centerのクライアント操作・監視機能 - 有線・無線クライアントのリスト表示・フィルタリング、MACアドレスによる詳細なクライアント検索、クライアント数分析、時間軸での分析、SSIDおよび周波数帯によるフィルタリング、無線トラブルシューティング機能を提供します。MACアドレスやIPアドレスでのクライアント検索、サイト別やSSID別のクライアント数集計、無線周波数帯の分布分析、Wi-Fi信号の問題調査が必要な場合に活用できます。
ci-cd-and-automation
CI/CDパイプラインの設定を自動化します。ビルドおよびデプロイメントパイプラインの構築または変更時に使用できます。品質ゲートの自動化、CI内のテストランナー設定、またはデプロイメント戦略の確立が必要な場合に活用します。
shipping-and-launch
本番環境へのリリース準備を行います。本番環境へのデプロイ準備が必要な場合、リリース前チェックリストが必要な場合、監視機能の設定を行う場合、段階的なロールアウトを計画する場合、またはロールバック戦略が必要な場合に使用します。
linear-release-setup
Linear Releaseに向けたCI/CD設定を生成します。リリース追跡の設定、LinearのCIパイプライン構築、またはLinearリリースとのデプロイメント連携を実施する際に利用できます。GitHub Actions、GitLab CI、CircleCIなど複数のプラットフォームに対応しています。
tracking-application-response-times
API エンドポイント、データベースクエリ、サービスコール全体にわたるアプリケーションのレスポンスタイムを追跡・最適化できます。パフォーマンス監視やボトルネック特定の際に活用してください。「レスポンスタイムを追跡する」「API パフォーマンスを監視する」「遅延を分析する」といった表現で呼び出せます。