コントリビューションガイド
このページで分かること
- EmDashのリポジトリの構成（pnpmのモノレポ、
packages/coreとpackages/admin）と、CONTRIBUTING.mdが正本であること - ローカルの開発環境の作り方（クローン、ビルド、デモの起動、管理画面を開く）と、ウォッチモード・必須のチェック・テストの実行方法
- 貢献の種類ごとの進め方（バグ修正・ドキュメント・翻訳は直接プルリクエスト、機能追加とリファクタリングはメンテナーが承認したDiscussionが先に必要）
このページの目次
EmDashは、pnpmのモノレポです。中心になるパッケージは packages/core で、emdash として公開されています。このパッケージには、Astroのインテグレーション、REST API、データベース層、スキーマの管理、プラグインの仕組みが含まれています。Reactで作られた管理画面は packages/admin にあります。
このページでは、動く開発環境をいちばん早く用意する方法を説明します。前提条件、リポジトリの構成、貢献のポリシー、必須のチェック、changeset、プルリクエストの要件については、CONTRIBUTING.md が正式な情報源です。
ローカル環境の準備
-
ワークスペースをクローンし、インストールしてビルドします。
git clone https://github.com/emdash-cms/emdash.git cd emdash pnpm install pnpm build -
主に使う開発用のデモを起動します。
cd demos/simple pnpm devデモは、Node.jsとSQLiteを使い、
http://localhost:4321で動きます。空のデータベースへの最初のリクエストで、seed/seed.jsonのサンプルコンテンツも適用します。 -
管理画面を開きます。
ローカル環境をいちばん早く用意するには、開発用のバイパスを開きます。マイグレーションを実行し、開発用の管理者を作成してサインインし、管理画面にリダイレクトします。
代わりにパスキーのセットアップの流れをテストするには、管理画面を開きます。セットアップウィザードがデータベースを作成してマイグレーションを実行し、管理者アカウントの作成を求めます。
開発の流れ
ウォッチモード
デモを動かしながら packages/core を変更する場合は、ターミナルを2つ使い、パッケージが自動的に再ビルドされるようにします。
# Terminal 1 — rebuild packages/core on change
cd packages/core && pnpm dev
# Terminal 2 — run the demo
cd demos/simple && pnpm dev
チェック
コミットする前に、リポジトリのルートで必須のチェックを実行します。
pnpm typecheck # TypeScript
pnpm lint # full type-aware lint
pnpm format # auto-format with oxfmt and Prettier
テスト
すべてのテスト
pnpm test
コアのみ
cd packages/core && pnpm test
ウォッチモード
cd packages/core && pnpm test --watch
E2E
pnpm test:e2e # starts its own server
テストでは、データベースのモックではなく、実際のインメモリのSQLiteデータベースを使います。テストごとに新しいデータベースが用意されます。
貢献の進め方の選択
バグ修正、ドキュメント、翻訳は、直接プルリクエストを送れます。バグ修正には、問題を再現する失敗するテストを含める必要があります。翻訳の貢献は、翻訳の進め方に従います。
機能追加とリファクタリングは、実装の前に、メンテナーが承認したDiscussionが必要です。承認のない機能追加のプルリクエストはクローズされます。どの進め方に当てはまるかが分かるように、作業を始める前に貢献のポリシーの全文を読みます。
ドキュメントの変更は、ドキュメントスタイルガイドにも従う必要があります。
EmDashの主な処理の流れについては、内部アーキテクチャを読みます。コードレベルのパターンと不変条件は、AGENTS.md に記載されています。
やさしい解説
WordPress本体の開発に参加するときと同じく、EmDash本体への貢献は、公式リポジトリのコードを手元で動かすところから始まります。このページの手順では、リポジトリをクローンしてビルドし、demos/simple のデモを起動します。バグ修正・ドキュメント・翻訳はそのままプルリクエストを送れますが、機能追加とリファクタリングは、先にDiscussionでメンテナーの承認を得る必要があります。承認のない機能追加のプルリクエストはクローズされるので、作業の前に CONTRIBUTING.md を読みます。