https://zenn.dev/hayato94087/articles/d2956e662202a7

ワークスペースの作成

turborepoはモノレポそれ自体をworkspaceと呼んで管理している。

npx create-turbo@latest

プロジェクトの雛形ができたら、トップレベルのpackage.jsonにパッケージ分割の単位を指定する。アプリ用とライブラリ用で分けるのを公式は推奨している。

パッケージの構造

例えばサンプルのapps/docs/pakcage.jsonを見てみると、

{
  "name": "docs",
  "version": "0.1.0",
  "type": "module",
  "private": true,
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build",
    "start": "next start",
    "lint": "next lint --max-warnings 0",
    "check-types": "tsc --noEmit"
  },
  "dependencies": {
    "@repo/ui": "*",
    "next": "^15.1.0",
    "react": "^19.0.0",
    "react-dom": "^19.0.0"
  },
  "devDependencies": {
    "@repo/eslint-config": "*",
    "@repo/typescript-config": "*",
    "@types/node": "^20",
    "@types/react": "18.3.1",
    "@types/react-dom": "18.3.0",
    "typescript": "5.5.4"
  }
}

のようになっている。

package.jsonのフィールドの意味

scripts

普通にnpmとかのscriptsと同じ。turbo.jsonで指定したコマンドに対応させておくとプロジェクトのルートでturbo xxxとしたら一斉に動いてくれる

name

パッケージの識別用さっき。turbo xxxとしたら一斉に動くと言ったが、動いてほしくないときもある。ういう時は--filterというオプションをつけるが、そこで指定する識別名がこれになる。

exports

あるパッケージの内容を他のパッケージからも使いたい場合なんかに利用する。

サンプルで言えば、

  "exports": {
    "./button": "./src/button.tsx",
    "./card": "./src/card.tsx",
    "./code": "./src/code.tsx"
  },

となっている。

これを使う側はどうなってるのか？を見てみると、

import Image, { type ImageProps } from "next/image";
import { Button } from "@repo/ui/button";
import styles from "./page.module.css";

@repo/ui ?? となるが、これはpackages/ui/package.jsonのnameでそう書いてるから認識できるっぽい。

依存関係の管理

npm install jest --workspace=web --workspace=@repo/ui --save-dev

ベストプラクティス

• ルートにいれるライブラリはモノレポ管理に関係するものだけ
• 書くパッケージごとにライブラリを入れるべき
  • Turborepoを使ってる時点でまあまあ大規模なプロジェクトになる
  • チームごとに触るパッケージが違ってきたりする
  • パッケージを跨いでライブラリ管理をすると、Aというパッケージでバージョン上げられてもBというパッケージでは上げられない、みたいなパターンが起こった時に対応できなくなって詰む
• ルートに依存関係が多いとキャッシュミスの機会も増える

内部パッケージ

たぶんTurborepoの強力な機能の一つ。

packagesに共通のパッケージを追加して使いまわせるようにする。

追加方法

• package/*に新しいパッケージを追加する。
• 追加したパッケージの下にpackage.jsonを作る
• 追加したパッケージを使いたい側のパッケージのpackage.jsonのdependenciesに新しく作ったパッケージ名を追加する
  • 依存関係が増えるので、npm install --workspace=dependenciesをいじったパッケージ としてあげる

ベストプラクティス

• そのパッケージが持つ役割はひとつ
• パッケージごとの依存関係はできるだけ少なく