tRPC End-to-End Type Safe APIs · レッスン

tRPCモノレポの設定

tRPCプロジェクト用のモノレポワークスペースを設定し、バックエンド、フロントエンド、共有型を分離します。

「tRPCモノレポの設定」はCoddyKit上の無料tRPC End-to-End Type Safe APIsレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはtRPC End-to-End Type Safe APIs学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 tRPC End-to-End Type Safe APIsコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

What is a Monorepo?

Welcome to setting up a tRPC project in a monorepo! But what exactly is a monorepo?

A monorepo is a single repository containing multiple distinct projects.
Unlike a polyrepo (multiple repos for multiple projects), everything lives together.
Think of it as a big folder holding many smaller, related projects.

It's a powerful way to manage complex applications.

Why Monorepos for tRPC?

Monorepos offer unique advantages when working with tRPC:

Shared Types: Easily share TypeScript types between your frontend and backend.
Atomic Commits: Changes to the API and its consuming client can be committed together.
Simplified Refactoring: Rename a type in one place, and your editor updates everywhere.
Consistent Tooling: Share configurations for linters, formatters, and build tools.

This approach makes end-to-end type safety even more robust.

Choosing a Monorepo Tool

To manage a monorepo effectively, you'll need a workspace manager. These tools help link your internal packages.

Popular options include:

pnpm Workspaces: Efficient, uses symlinks for dependencies.
Yarn Workspaces: A common choice, built into Yarn.
Nx: A powerful build system and monorepo tool.
Turborepo: Focuses on fast builds and caching.

For this lesson, we'll use pnpm Workspaces due to its simplicity and efficiency.

Initializing the Monorepo

First, create a new directory for your monorepo and initialize a `package.json`.

Then, create a `pnpm-workspace.yaml` file to define your workspace roots. This tells pnpm where to find your sub-projects.

mkdir trpc-monorepo
cd trpc-monorepo
pnpm init

# pnpm-workspace.yaml
packages:
  - 'packages/*'

Structuring the 'packages' Folder

The `packages` directory will contain all your individual projects (or 'apps'). We'll typically have:

server: Your tRPC backend.
client: Your frontend application (e.g., React, Next.js).
shared: A package for common utilities, types, and Zod schemas shared by `server` and `client`.

Let's create these basic directories.

mkdir -p packages/server
mkdir -p packages/client
mkdir -p packages/shared

Setting up the 'server' Package

Inside `packages/server`, we'll set up a basic Node.js project. It needs its own `package.json` and `tsconfig.json`.

The `tsconfig.json` will specify compilation options for your backend code.

// packages/server/package.json
{
  "name": "server",
  "version": "1.0.0",
  "main": "src/index.ts",
  "scripts": {
    "dev": "ts-node-dev src/index.ts"
  },
  "dependencies": {
    "@trpc/server": "latest",
    "cors": "latest",
    "express": "latest"
  },
  "devDependencies": {
    "typescript": "latest",
    "ts-node-dev": "latest"
  }
}

// packages/server/tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true,
    "outDir": "dist"
  }
}

Setting up the 'client' Package

Similarly, `packages/client` will house your frontend application. This example shows a basic React setup, but it could be Next.js or any other framework.

It will also have its own `package.json` and `tsconfig.json`.

// packages/client/package.json
{
  "name": "client",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "vite"
  },
  "dependencies": {
    "@trpc/client": "latest",
    "@trpc/react-query": "latest",
    "react": "latest",
    "react-dom": "latest",
    "@tanstack/react-query": "latest"
  },
  "devDependencies": {
    "typescript": "latest",
    "vite": "latest",
    "@vitejs/plugin-react": "latest"
  }
}

// packages/client/tsconfig.json
{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx"
  },
  "include": ["src"],
  "references": [{ "path": "../shared" }]
}

Creating the 'shared' Package

The `packages/shared` directory is crucial for tRPC monorepos. It will contain types and definitions that both your `server` and `client` need.

This ensures end-to-end type safety by having a single source of truth for your API contract.

// packages/shared/package.json
{
  "name": "shared",
  "version": "1.0.0",
  "main": "src/index.ts",
  "types": "src/index.ts"
}

// packages/shared/tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "declaration": true,
    "outDir": "dist"
  },
  "include": ["src"]
}

Linking Shared Types

Now that we have our `shared` package, we need to tell `server` and `client` about it.

We add `"shared": "workspace:*"` to the `dependencies` of both `server` and `client`'s `package.json` files.

Then, run `pnpm install` at the monorepo root to link them up.

// packages/server/package.json (snippet)
"dependencies": {
  "@trpc/server": "latest",
  "shared": "workspace:*" // Add this line!
}

// packages/client/package.json (snippet)
"dependencies": {
  "@trpc/client": "latest",
  "shared": "workspace:*" // Add this line!
}

pnpm install

Practical Example: Sharing a Type

Let's see how sharing types works. We'll define a `User` type in `shared` and use it in a mock backend and frontend snippet.

This demonstrates the core benefit: defining types once and using them everywhere.

// packages/shared/src/index.ts
export type User = {
  id: string;
  name: string;
  email: string;
};

// packages/server/src/index.ts (mock)
import { User } from 'shared';

const getUser = (): User => ({
  id: '123',
  name: 'Alice',
  email: 'alice@example.com'
});

console.log(getUser().name);

// packages/client/src/App.tsx (mock)
import { User } from 'shared';

const displayUser = (user: User) => {
  console.log(`User: ${user.name}`);
};

const currentUser: User = {
  id: '456',
  name: 'Bob',
  email: 'bob@example.com'
};
displayUser(currentUser);

Monorepo Setup Check

You've learned about setting up a tRPC monorepo. Which of the following is NOT a primary benefit of using a monorepo for a tRPC project?

Recap: tRPC Monorepo Setup

You've successfully explored how to set up a tRPC monorepo!

We defined a monorepo as a single repository for multiple projects.
Learned its benefits for tRPC, especially shared types.
Used `pnpm Workspaces` to structure `server`, `client`, and `shared` packages.
Understood how to link these packages to share code and types.

This foundation is key for building scalable and type-safe tRPC applications!

よくある質問

「tRPCモノレポの設定」レッスンは無料ですか？

はい。「tRPCモノレポの設定」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、tRPC End-to-End Type Safe APIsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 tRPC End-to-End Type Safe APIsコースには全4レッスンが含まれています。

「tRPCモノレポの設定」で何を学びますか？

tRPCプロジェクト用のモノレポワークスペースを設定し、バックエンド、フロントエンド、共有型を分離します。ブラウザで直接実行するハンズオンコードでtRPC End-to-End Type Safe APIsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

tRPC End-to-End Type Safe APIsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのtRPC End-to-End Type Safe APIsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「tRPCモノレポの設定」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このtRPC End-to-End Type Safe APIsレッスンでコードを書いて実行できますか？

はい。すべてのtRPC End-to-End Type Safe APIsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← tRPC End-to-End Type Safe APIsに戻る