shared-monorepo-turborepo
Turborepoを活用したモノレポ構成で、効率的なパッケージ管理や依存関係の最適化を行い、大規模なJavaScript/TypeScriptプロジェクトをスムーズに進めるSkill。
📜 元の英語説明(参考)
Turborepo, workspaces, package architecture, @repo/* naming, exports, tree-shaking
🇯🇵 日本人クリエイター向け解説
Turborepoを活用したモノレポ構成で、効率的なパッケージ管理や依存関係の最適化を行い、大規模なJavaScript/TypeScriptプロジェクトをスムーズに進めるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o shared-monorepo-turborepo.zip https://jpskill.com/download/10264.zip && unzip -o shared-monorepo-turborepo.zip && rm shared-monorepo-turborepo.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10264.zip -OutFile "$d\shared-monorepo-turborepo.zip"; Expand-Archive "$d\shared-monorepo-turborepo.zip" -DestinationPath $d -Force; ri "$d\shared-monorepo-turborepo.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
shared-monorepo-turborepo.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
shared-monorepo-turborepoフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Turborepo による Monorepo オーケストレーション
クイックガイド: monorepo オーケストレーションのための Turborepo 2.x。依存関係の順序付けによるタスクパイプライン。大幅な速度向上のためのローカル + リモートキャッシュ。パッケージリンキングのためのワークスペース。依存関係のバージョン整合性のための Syncpack。内部パッケージは
@repo/*の命名、明示的なexportsフィールド、およびworkspace:*プロトコルを使用します。
<critical_requirements>
重要: この Skill を使用する前に
すべてのコードは CLAUDE.md のプロジェクト規約に従う必要があります (kebab-case、名前付きエクスポート、インポート順序、
import type、名前付き定数)
(トポロジカルな順序付けを確実にするために、turbo.json で dependsOn: ["^build"] を使用してタスクの依存関係を定義する必要があります)
(適切なキャッシュの無効化のために、turbo.json タスクの env 配列にすべての環境変数を宣言する必要があります)
(開発サーバーやコード生成のような副作用のあるタスクには cache: false を設定する必要があります)
*(内部パッケージの依存関係には `workspace:` プロトコルを使用する必要があります)**
*(すべての内部パッケージに `@repo/` の命名規則を使用する必要があります)**
(package.json で明示的な exports フィールドを定義する必要があります - 内部パスのインポートは絶対に許可しないでください)
(コンポーネントパッケージでは React を dependencies ではなく peerDependencies としてマークする必要があります)
</critical_requirements>
自動検出: Turborepo 構成、turbo.json、monorepo セットアップ、ワークスペース、Bun ワークスペース、syncpack、タスクパイプライン、@repo/* パッケージ、package.json exports、ワークスペースの依存関係、共有構成
使用する場面:
- Turborepo タスクパイプラインとキャッシュ戦略の構成
- monorepo パッケージリンキングのためのワークスペースのセットアップ
- チーム/CI キャッシュ共有のためのリモートキャッシュの有効化
- ワークスペースパッケージ間の依存関係のバージョン同期
packages/での新しい内部パッケージの作成- ツリーシェイキングのための package.json exports の構成
- 共有構成パッケージ (@repo/eslint-config, @repo/typescript-config) のセットアップ
使用しない場面:
- 単一アプリケーションプロジェクト (標準のビルドツールを直接使用)
- 共有パッケージのないプロジェクト (monorepo の利点がない)
- セットアップのオーバーヘッドがキャッシュの利点を上回る非常に小さなプロジェクト
- monorepo よりも polyrepo アーキテクチャが優先される場合
- すでに Nx または Lerna を使用しているプロジェクト (monorepo ツールを混在させない)
- 共有されないアプリ固有のコード (アプリディレクトリに保持)
カバーする主要なパターン:
- Turborepo 2.x タスクパイプライン (dependsOn, outputs, inputs, cache)
- ローカルおよびリモートのキャッシュ戦略
- パッケージリンキングのためのワークスペース
- 依存関係のバージョン整合性のための Syncpack
- turbo.json での環境変数の処理
- パッケージ構造と @repo/* の命名規則
- ツリーシェイキングのための package.json exports
- 名前付きエクスポートとバレルファイルのパターン
- ワークスペースプロトコルによる内部依存関係
詳細なリソース:
- コード例については、examples/core.md を参照してください (常にここから始めてください)
- examples/caching.md - リモートキャッシュ、CI/CD 統合
- examples/workspaces.md - ワークスペースプロトコル、syncpack、依存関係の境界
- examples/packages.md - 内部パッケージの規約、exports、パッケージの作成
- 意思決定フレームワークとアンチパターンについては、reference.md を参照してください
<philosophy>
Philosophy
Turborepo は、JavaScript/TypeScript monorepo 向けに設計された高性能なビルドシステムです。インテリジェントなタスクスケジューリング、キャッシュ、およびリモートキャッシュ共有を提供し、ビルド時間を劇的に短縮します。ワークスペースと組み合わせることで、自動依存関係リンキングによる効率的なパッケージ管理が可能になります。
</philosophy>
<patterns>
コアパターン
パターン 1: 依存関係の順序付けによる Turborepo タスクパイプライン
インテリジェントなビルドオーケストレーションとキャッシュを有効にするために、turbo.json でタスクの依存関係とキャッシュの動作を定義します。
主要な概念
dependsOn: ["^build"]- 依存関係のあるタスクを最初に実行します (トポロジカル順)outputs- キャッシュするファイルを定義しますinputs- キャッシュの無効化をトリガーするファイルを指定しますcache: false- 副作用のあるタスクのキャッシュを無効にしますpersistent: true- 開発サーバーを実行し続けます
最小限の例
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"env": ["DATABASE_URL", "NODE_ENV"],
"outputs": ["dist/**", ".next/**", "!.next/cache/**"]
},
"dev": { "cache": false, "persistent": true }
}
}
キー: dependsOn: ["^build"] はトポロジカルな実行を保証し、env はキャッシュの無効化のための変数を宣言し、cache: false は副作用のあるタスクのために使用します。
完全な良い例/悪い例の比較については、examples/core.md を参照してください。
パターン 2: キャッシュ戦略
Turborepo のキャッシュシステムは、入力が変更されていない場合に以前のタスクの出力を再利用することで、ビルドを大幅に高速化します。
キャッシュされるもの
- ビルド出力 (
dist/,.next/, フレームワーク固有のディレクトリ) - テスト結果 (
cache: trueの場合) - リント結果
キャッシュされないもの
- 開発サーバー (
cache: false) - コード生成 (
cache: false- ファイルを生成) - 副作用のあるタスク
キャッシュの無効化トリガー
- ソースファイルの変更
- 依存関係の変更
- 環境変数の変更 (
env配列にある場合) - グローバルな依存関係の変更 (
.env,tsconfig.json)
セットアップ: Vercel アカウント (またはセルフホストキャッシュ) をリンクし、TURBO_TOKEN および TURBO_TEAM 環境変数を設定して、リモートキャッシュ共有を有効にします。
リモートキャッシュの構成と CI 統合の例については、examples/caching.md を参照してください。
パターン 3: パッケージ管理のためのワークスペース
ワークスペースを構成して、monorepo パッケージ全体でパッケージのリンクと依存関係の共有を有効にします。
主要な概念
- ルート
package.jsonは"workspaces": ["apps/*", "packages/*"]を宣言します - 内部依存関係は自動リンキングのために
"@repo/ui": "workspace:*"プロトコルを使用します - 標準的な構造: デプロイ可能なアプリのための
apps/、共有コードのためのpackages/
完全な良い例/悪い例の比較については、examples/workspaces.md を参照してください。
(原文がここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Monorepo Orchestration with Turborepo
Quick Guide: Turborepo 2.x for monorepo orchestration. Task pipelines with dependency ordering. Local + remote caching for massive speed gains. Workspaces for package linking. Syncpack for dependency version consistency. Internal packages use
@repo/*naming, explicitexportsfields, andworkspace:*protocol.
<critical_requirements>
CRITICAL: Before Using This Skill
All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering,
import type, named constants)
(You MUST define task dependencies using dependsOn: ["^build"] in turbo.json to ensure topological ordering)
(You MUST declare all environment variables in the env array of turbo.json tasks for proper cache invalidation)
(You MUST set cache: false for tasks with side effects like dev servers and code generation)
*(You MUST use `workspace:` protocol for internal package dependencies)**
*(You MUST use `@repo/` naming convention for ALL internal packages)**
(You MUST define explicit exports field in package.json - never allow importing internal paths)
(You MUST mark React as peerDependencies NOT dependencies in component packages)
</critical_requirements>
Auto-detection: Turborepo configuration, turbo.json, monorepo setup, workspaces, Bun workspaces, syncpack, task pipelines, @repo/* packages, package.json exports, workspace dependencies, shared configurations
When to use:
- Configuring Turborepo task pipeline and caching strategies
- Setting up workspaces for monorepo package linking
- Enabling remote caching for team/CI cache sharing
- Synchronizing dependency versions across workspace packages
- Creating new internal packages in
packages/ - Configuring package.json exports for tree-shaking
- Setting up shared configuration packages (@repo/eslint-config, @repo/typescript-config)
When NOT to use:
- Single application projects (use standard build tools directly)
- Projects without shared packages (no monorepo benefits)
- Very small projects where setup overhead exceeds caching benefits
- Polyrepo architecture is preferred over monorepo
- Projects already using Nx or Lerna (don't mix monorepo tools)
- App-specific code that won't be shared (keep in app directory)
Key patterns covered:
- Turborepo 2.x task pipeline (dependsOn, outputs, inputs, cache)
- Local and remote caching strategies
- Workspaces for package linking
- Syncpack for dependency version consistency
- Environment variable handling in turbo.json
- Package structure and @repo/* naming conventions
- package.json exports for tree-shaking
- Named exports and barrel file patterns
- Internal dependencies with workspace protocol
Detailed Resources:
- For code examples, see examples/core.md (always start here)
- examples/caching.md - Remote caching, CI/CD integration
- examples/workspaces.md - Workspace protocol, syncpack, dependency boundaries
- examples/packages.md - Internal package conventions, exports, creating packages
- For decision frameworks and anti-patterns, see reference.md
<philosophy>
Philosophy
Turborepo is a high-performance build system designed for JavaScript/TypeScript monorepos. It provides intelligent task scheduling, caching, and remote cache sharing to dramatically reduce build times. Combined with workspaces, it enables efficient package management with automatic dependency linking.
</philosophy>
<patterns>
Core Patterns
Pattern 1: Turborepo Task Pipeline with Dependency Ordering
Define task dependencies and caching behavior in turbo.json to enable intelligent build orchestration and caching.
Key Concepts
dependsOn: ["^build"]- Run dependency tasks first (topological order)outputs- Define what files to cacheinputs- Specify which files trigger cache invalidationcache: false- Disable caching for tasks with side effectspersistent: true- Keep dev servers running
Minimal Example
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"env": ["DATABASE_URL", "NODE_ENV"],
"outputs": ["dist/**", ".next/**", "!.next/cache/**"]
},
"dev": { "cache": false, "persistent": true }
}
}
Key: dependsOn: ["^build"] ensures topological execution, env declares variables for cache invalidation, cache: false for side-effect tasks.
See examples/core.md for full good/bad comparison examples.
Pattern 2: Caching Strategies
Turborepo's caching system dramatically speeds up builds by reusing previous task outputs when inputs haven't changed.
What Gets Cached
- Build outputs (
dist/,.next/, framework-specific directories) - Test results (when
cache: true) - Lint results
What Doesn't Get Cached
- Dev servers (
cache: false) - Code generation (
cache: false- generates files) - Tasks with side effects
Cache Invalidation Triggers
- Source file changes
- Dependency changes
- Environment variable changes (when in
envarray) - Global dependencies changes (
.env,tsconfig.json)
Setup: Link a Vercel account (or self-hosted cache), then set TURBO_TOKEN and TURBO_TEAM environment variables to enable remote cache sharing.
See examples/caching.md for remote caching configuration and CI integration examples.
Pattern 3: Workspaces for Package Management
Configure workspaces to enable package linking and dependency sharing across monorepo packages.
Key Concepts
- Root
package.jsondeclares"workspaces": ["apps/*", "packages/*"] - Internal deps use
"@repo/ui": "workspace:*"protocol for automatic linking - Standard structure:
apps/for deployable apps,packages/for shared code
See examples/workspaces.md for full good/bad comparison examples and syncpack configuration.
</patterns>
<performance>
Performance Optimization
Cache Hit Metrics:
- First build: ~45s (5 packages, no cache)
- Cached build: ~1s (97% faster with local cache)
- Affected build: ~12s (73% faster, only changed packages rebuild)
- Team savings: Hours per week with remote cache enabled
Optimization Strategies:
- Set
globalDependenciesfor files affecting all packages (.env,tsconfig.json) to prevent unnecessary cache invalidation - Use
inputsarray to fine-tune what triggers cache invalidation for specific tasks - Enable remote caching to share artifacts across team and CI
- Use
--filterwith affected detection (--filter=...[HEAD^]) to only run tasks for changed packages - Set
outputscarefully to exclude cache directories (e.g.,!.next/cache/**)
Force Cache Bypass:
# Ignore cache when needed
bun run build --force
# Only build affected packages
bun run build --filter=...[HEAD^1]
</performance>
<decision_framework>
Decision Framework
New code? → Shared across 2+ apps? → packages/ (else keep in app)
Monorepo? → Builds > 30s or caching matters? → Use Turborepo
For comprehensive decision trees and package creation criteria, see reference.md.
</decision_framework>
<red_flags>
RED FLAGS
High Priority Issues:
- Missing
dependsOn: ["^build"]for build tasks (breaks topological ordering) - Missing
envarray in turbo.json (causes cache misses across environments) - Caching dev servers or code generation (incorrect outputs reused)
- Default exports in library packages (breaks tree-shaking)
- Missing
exportsfield in package.json (allows internal path imports)
Common Mistakes:
- Hardcoded versions instead of
workspace:*for internal deps - React in
dependenciesinstead ofpeerDependencies - Giant barrel files re-exporting everything (negates tree-shaking)
- Running full test suite without
--filter=...[HEAD^]affected detection
Gotchas:
dependsOn: ["^task"]runs dependencies' tasks;dependsOn: ["task"]runs same package's task--filter=...[HEAD^]requiresfetch-depth: 2in GitHub Actions- Exclude cache directories in outputs:
!.next/cache/**
For detailed anti-patterns and checklists, see reference.md.
</red_flags>
<critical_reminders>
CRITICAL REMINDERS
All code must follow project conventions in CLAUDE.md
(You MUST define task dependencies using dependsOn: ["^build"] in turbo.json to ensure topological ordering)
(You MUST declare all environment variables in the env array of turbo.json tasks for proper cache invalidation)
(You MUST set cache: false for tasks with side effects like dev servers and code generation)
*(You MUST use `workspace:` protocol for internal package dependencies)**
*(You MUST use `@repo/` naming convention for ALL internal packages)**
(You MUST define explicit exports field in package.json - never allow importing internal paths)
(You MUST mark React as peerDependencies NOT dependencies in component packages)
Failure to follow these rules will cause incorrect builds, cache misses, broken dependency resolution, and tree-shaking failures.
</critical_reminders>