EmDash CMS プロジェクトのブートストラップとディレクトリ構成

公開日 2026-04-08 著者 Emdash Cms Everything

このガイドの対象

空のリポジトリから始め、次を支えるディレクトリ構造が欲しいときに使います。

• 毎日の編集コンテンツ変更
• CMS の前提を壊さないフロントエンドの反復
• 後からローカル開発から Cloudflare へのデプロイ移行

目標は、最も賢いフォルダツリーを作ることではありません。長期的な保守コストを下げることです。

まずランタイムの判断から

ファイルを作る前に、今後 30〜90 日でどのランタイムを最適化するか決めます。

• 最速のローカルオンボーディングと最低の運用複雑さなら Node.js + SQLite
• 本番 SSR、マネージドストレージ、EmDash プラグインモデルとのより密な統合なら Cloudflare Workers + D1 + R2

コンテンツ戦略をまだ検証中なら、まず Node.js から始め、初日から Cloudflare 向けの命名を保ちます。早期のプラットフォームロックインを避けつつ、移行は単純に保てます。

推奨のベースライン構成

your-emdash-site/
├── src/
│   ├── components/            # 再利用 UI のみ
│   ├── layouts/               # 共通ページシェル
│   ├── pages/                 # Astro ルート
│   ├── lib/                   # ドメインロジックと連携
│   ├── styles/                # グローバルと共有スタイルトークン
│   └── live.config.ts         # ライブコンテンツコレクションのマッピング
├── seed/                      # ブートストラップ／デモ用シードデータ
├── public/                    # 静的アセット（ファビコン、静的画像）
├── docs/                      # 製品ドキュメントと編集コンテンツ（MDX）
├── astro.config.mjs
├── package.json
├── tsconfig.json
└── emdash-env.d.ts

既存プロジェクトが lib/ の代わりに utils/ を使っているなら、明確な所有ルールを強制できるまでそのままにします。

ディレクトリの所有モデル

構造が機能するのは、所有が明示されているときだけです。

• src/components: プレゼンテーションのみ。DB やストレージを直接呼ばない
• src/layouts: 共通フレーム（head、ナビ枠、フッターシェル）
• src/pages: レンダリングのルート構成とデータ配線
• src/lib: ビジネスルール、データアダプタ、プラットフォーム固有の接着剤
• seed: 新しい環境向けの再現可能なベースラインコンテンツ

この分離で、最もよくある漂流——ユーティリティコードが黙ってビジネスロジックになる——を防ぎます。

やり直しを避けるブートストラップの流れ

本番向けプロジェクトでは次の順序を使います。

1. 公式の足場で作成する
2. テンプレートを一つ選ぶ（ブログ、マーケティング、ポートフォリオ）
3. 明確なチーム標準と衝突しない限り、生成された慣習を保つ
4. 構造のカスタムは一度に一つだけ追加する

この順序が重要な理由: 多くの公開遅れは機能不足ではなく、後からドキュメント・スクリプト・オンボーディングを壊す早期の構造の分岐から来ます。

推奨のブートストラップコマンド

# 新しい EmDash CMS プロジェクトを足場組み
npm create emdash@latest my-emdash-site
cd my-emdash-site

# インストールしてローカル開発を開始
npm install
npm run dev

避けるべきよくあるアンチパターン

1) コンテンツモデルの判断なしのルートファースト実装

コレクションとタクソノミーの形に合意する前にページルートを作ると、高価な書き直しを招きます。

2) UI フォルダへのデプロイ関心の混入

デプロイ専用のスクリプトや設定ヘルパーを components や pages に置かない。プラットフォームの関心は設定ファイルと src/lib に置きます。

3) 境界のない utils フォルダ

すべてが utils に入ると発見可能性が崩れます。src/lib/content、src/lib/media、src/lib/auth のような名前付きドメインを優先します。

初期セットアップ完了の定義

次のチェックがすべて通るまで、ブートストラップは完了とみなしません。

• ローカル開発サーバーが手パッチなしで動く
• サンプルのコンテンツフローが端到端で動く
• シードデータを新しい環境にインポートできる
• CI ビルドが環境固有のハックなしで通る
• 新しいコントリビュータが 10 分以内にリポジトリを把握できる

次にすること

構造が安定したら:

1. リポジトリにランタイムの選択と移行基準を文書化する
2. ボリュームが増える前にコンテンツタイプの命名規則を定義する
3. 選んだプラットフォーム向けのデプロイランブックを実装する

ディレクトリ構成は装飾ではなくアーキテクチャです。早めに固めると、後で何週間も節約できます。