jpskill.com
🛠️ 開発・MCP コミュニティ

shared-monorepo-turborepo

Turborepoを活用したモノレポ構成で、効率的なパッケージ管理や依存関係の最適化を行い、大規模なJavaScript/TypeScriptプロジェクトをスムーズに進めるSkill。

📜 元の英語説明(参考)

Turborepo, workspaces, package architecture, @repo/* naming, exports, tree-shaking

🇯🇵 日本人クリエイター向け解説

一言でいうと

Turborepoを活用したモノレポ構成で、効率的なパッケージ管理や依存関係の最適化を行い、大規模なJavaScript/TypeScriptプロジェクトをスムーズに進めるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して shared-monorepo-turborepo.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → shared-monorepo-turborepo フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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 を参照してください (常にここから始めてください)
  • 意思決定フレームワークとアンチパターンについては、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, explicit exports fields, and workspace:* 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:


<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 cache
  • inputs - Specify which files trigger cache invalidation
  • cache: false - Disable caching for tasks with side effects
  • persistent: 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 env array)
  • 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.json declares "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 globalDependencies for files affecting all packages (.env, tsconfig.json) to prevent unnecessary cache invalidation
  • Use inputs array to fine-tune what triggers cache invalidation for specific tasks
  • Enable remote caching to share artifacts across team and CI
  • Use --filter with affected detection (--filter=...[HEAD^]) to only run tasks for changed packages
  • Set outputs carefully 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 env array 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 exports field in package.json (allows internal path imports)

Common Mistakes:

  • Hardcoded versions instead of workspace:* for internal deps
  • React in dependencies instead of peerDependencies
  • 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^] requires fetch-depth: 2 in 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>