プロジェクト構造

インストールとセットアップ

手順の前に、始める前に と ターミナルの基本 をお読みください。これらの手順では、VS Code で完全な supastack モノリポジトリを開いたことが前提となっています。そのルート package.json はリポジトリのルートをマークします。 pnpm コマンドでは、ワークスペース パッケージはアプリまたは共有コード フォルダーです。この製品では、ワークスペースはチームのデータ コンテナであり、セキュリティ境界です。 corepack pnpm --filter ... コマンドがルートから実行されている間にモノリポジトリから 1 つのパッケージを選択します。同期されたモバイル フォルダーまたはデスクトップ フォルダーのみを開いた場合、そのフォルダーには Web バックエンド、Docker セットアップ、またはルート スクリプトが含まれていません。このモノリポジトリまたはアクセス可能なホスト サーバーからバックエンドを実行し、プラットフォーム フォルダー独自のスクリプトを使用します。環境変数は、ローカルの .env ファイルまたはホスティング ダッシュボードに保存される名前付き設定です。変更後に関連するアプリを再起動し、NEXT_PUBLIC_ および EXPO_PUBLIC_ 値にサーバー シークレットが含まれないようにします。

1. VS Code でルート package.json を開き、Web サイトの場合は apps/web、Expo の場合は apps/mobile、デスクトップ シェルの場合は apps/desktop、共有部分のパッケージは参照します。

2. リポジトリのルートから corepack pnpm --filter @supastack/web dev を実行します。

3. http://localhost:3000. を開く 予想: Web アプリは apps/web から開始されますが、共有パッケージはこの同じリポジトリに残ります。デスクトップ ウィンドウは、2 番目の製品を含むのではなく、この Web アプリをラップします。

pnpm ワークスペースには apps/web の Next.js、apps/mobile の Expo、packages 配下の共有パッケージが含まれます。ワークスペースコマンドはリポジトリルートから実行します。アプリケーションルートは共有モジュールを組み合わせ、製品固有の振る舞いは消費製品に属します。

振る舞いを変える前に AGENTS.md と .ai/PROJECT_CONTEXT.md を読んでください。.ai/ のファイルミラーは、単独のコンポーネントからは必ずしも明らかでない決定と制約を説明します。

apps/web/app/       Routes and layouts
packages/web-core/src/  Shared pages, components and server composition
apps/mobile/        Expo application
packages/           Shared contracts and adapters
tests/              Cross-module and browser checks
docs/               Operational guides

コピーするコマンド

コメントに従って、コマンドがどのフォルダーで実行されるかを確認します。 2 つのターミナルにラベルが付いている場合は、2 つのターミナル ウィンドウを開き、2 番目のコマンドを使用している間、最初のコマンドを実行し続けます。

corepack pnpm --filter @supastack/web dev

変更が属する場所

編集前に、どのアプリまたはパッケージがその変更を所有するかを決めます。目安として、1 つの製品サーフェスだけが必要とするならそのアプリに、すべてのサーフェスが必要とするなら packages/ 配下の共有パッケージに置きます。

Web リポジトリと All Platforms モノレポには以下のすべてのフォルダーが含まれます。スタンドアロンのモバイル・デスクトップのチェックアウトには自分のアプリだけが含まれます — サーバーコードは Web リポジトリに残ります。

• 最初の機能を作る

• 新しいマーケティング・ランディングページ → apps/web/app/ — 公開ウェブサイト。
• サインイン済み製品内の新しい画面 → ルートは apps/web/app/、ロジックは packages/web-core/src/ — ページは共有パッケージを組み合わせます。
• 新しい API ルート → apps/web/app/api/ — Web アプリのサーバー側。
• すべてのアプリが共有する変更 — データベーステーブル、コントラクト、プロバイダーアダプター → packages/ 内の対応するフォルダー。
• スマートフォン専用の画面 → apps/mobile/ — 独自のバックエンドを持たず、Web アプリの API と通信します。
• デスクトップ専用の動作 → apps/desktop/ — Tauri シェルは Web アプリをラップし、製品 UI をフォークすることはほとんどありません。

実装ワークフロー

ユーザーアクションを所有するルートから始め、そのサーバーハンドラーをたどり、それが呼ぶ共有パッケージを検査します。UI コンポーネントがワークスペース解決、課金認可、プロバイダー選択を再作成してはいけません。

ルートを追加するとき、公開か認証済みかを決めます。ユーザーレコードに触れる前にサーバーで認証済み所有権を解決し、サーバー認証情報をクライアントインポートの外に保ちます。

検証とトラブルシューティング

コマンドによって、フィルターに一致するプロジェクトがないことが報告された場合は、ターミナルがルートの package.json を含むフォルダーにあることを確認してください。ポート 3000 がすでに使用されている場合は、最初に他のローカル Web サーバーを停止します。個別のデスクトップ チャットまたはログインの実装を探さないでください。デスクトップ シェルは Web バックエンドをロードします。

パッケージコントラクトを変えた後、関連テストと型チェックを実行します。共有型を変えるときは Web とモバイルの消費者を検査します。成功した Web ビルドだけではネイティブアプリの互換性は確立されません。