godaddy-nodejs-hosting

GoDaddy Node.js ホスティング

ユーザーが GoDaddy Node.js ホスティング 用の Node.js アプリを構築または修正できるよう支援します（アップロード → インストール → run build → run start）。パッケージマネージャーは npm、pnpm、または yarn です（プラットフォームの選択はロックファイルによって決まります）。

ルール：contract.md。レシピ：examples.md。エラー：troubleshooting.md。メール：email.md。バリデーター：scripts/validate-paas.mjs。

用途に応じた参照先

ユーザーの意図	セクション
新しいアプリ／スキャフォールド／新規開発	新規アプリのワークフロー
既存のリポジトリ／デプロイに失敗した／ホスティングで動作するようにしたい	既存アプリの適応
AI によるエクスポート（Lovable、Replit、Bolt など）	既存アプリの適応 + AI エクスポートの簡易修正
MySQL／プラットフォーム上のデータベースを使用する	マネージド MySQL
メール／問い合わせフォーム／通知を送信する	メール

対象ユーザーに応じた案内

技術に詳しくないユーザー（専門用語を使わない。「Lovable で作りました」「アップロード方法を教えて」など）：

1. まず、アップロード前のチェックリストをわかりやすい言葉で提示します。
2. 既存アプリの適応に従います（既存の ZIP またはエクスポート）。
3. サーバーがない場合は、静的 SPA + Expressまたは静的ファイルのみのレシピを優先します。output: 'export'を指定した Next.js の場合は、代わりにnextjs-static-exportを使用し、「アプリは静的ファイルにビルドされます。GoDaddy で実行できるよう、小さなサーバーを追加します。サイト自体は変わりません」と説明します。
4. 変更は一度に小さく行い、次のホスティング手順（Git 同期または UI での ZIP アップロード）をわかりやすい言葉で説明します。
5. アプリの準備ができたと伝える前に、バリデーターを実行します。

技術に詳しいユーザー — 既存アプリ：既存アプリの適応に従い、start／buildのみ該当するフレームワークのレシピを使用します。基本事項を改めて説明しないでください。

技術に詳しいユーザー — 新規アプリ：新規アプリのワークフローに従い、フレームワークの判定から該当するフレームワークのレシピを使用します。

デプロイ要件（概要）

• ルートにname、version、main（ファイルが存在すること）、scripts.build、scripts.startを含むpackage.jsonがあること
• コンパイルが不要な場合、buildは"echo build"でも構いません。フレームワークでは実際のビルドコマンドが必要です（examples.md）
• process.env.PORTで待ち受けます。フレームワークでホストの指定が必要な場合は0.0.0.0を使用します
• ランタイム依存関係はdependenciesに記載し、node_modulesはアップロードしないでください
• シークレットにはprocess.envを使用します。ZIP に.envを含めないでください。ZIP は100 MB未満にします
• アップロードごとにアプリは1つにします。可能な場合はロックファイルを含めます
• 外部への通信は HTTP／HTTPS のみです。データベースを使う場合は、プラットフォームの MySQL をDB_*環境変数とmysql2で使用します（contract.md）
• メールにはプラットフォームのゲートウェイ（http://127.0.0.1:2525/api/email/send）を使用し、提供されているsendEmail()ヘルパーを使います。nodemailerや外部 SMTP は使用しません（email.md）

更新の公開（ユーザーへの案内）

プラットフォームは、Node.js Hosting の UI でGit リポジトリの同期とZIP アップロードに対応しています。エージェント向けの情報は、AGENTS.md の「デプロイフロー」を参照してください。

• .git、ロックファイル、またはエクスポート元からデプロイ方法を推測しないでください（ZIP エクスポートにローカル開発時の.gitが含まれる場合があります）。
• **公開方法をユーザーに案内するときの既定の表現：**中立的な言い方をしてください。例：「準備ができたら、Node.js Hosting で Git 同期またはホスティング UI からの ZIP アップロードを使ってアプリを更新できます。」
• ZIP の手順や Git の接続・プッシュなど、方法を限定した案内をするのは、ユーザーがどちらを使うか明言した場合、または尋ねた場合に限ります。
• その確認をせずに、「新しい ZIP をアップロードする」「リモートにプッシュする」など、特定の方法を指示する表現は避けてください。

マネージド MySQL

オプションのプラットフォーム MySQL では、DB_HOST、DB_PORT、DB_NAME、DB_USER、DB_PASSWORD が注入されます。アプリはそれぞれをハードコードせず、process.env から読み取る必要があります。dependencies で mysql2 を使用し、パラメーター化クエリを使ってください。

レシピ：examples.md#managed-mysql。バリデーター：DB クライアントまたは Prisma の MySQL プロバイダーが検出された場合は E009、E010。

メール

アプリは、プラットフォームに組み込まれたゲートウェイ http://127.0.0.1:2525/api/email/send を介して、トランザクションメール（お問い合わせフォーム、通知、領収書、パスワードリセット）を送信します。これはコンテナー内でのみアクセス可能なループバックアドレスです。SMTP 設定、nodemailer、サードパーティ API キーは不要です。コンテナーからは外部 SMTP にルーティングできません。

sendEmail() ヘルパーを src/server/email.ts にコピーし、ルートハンドラーから呼び出してください。すべてのメール送信コードでこのヘルパーを呼び出してください。ゲートウェイに直接 POST したり、nodemailer をインポートしたりしないでください。

重要なルール（詳細：email.md）：

• デフォルトでは from を省略してください。ゲートウェイがアプリの正規の送信者を選択します。from を設定する場合は、検証済みドメインのリテラル値をハードコードしてください（未検証の場合は 400）。ユーザー入力から設定しないでください。
• 固定の宛先（お問い合わせフォームの管理者、アラート）は process.env から取得します（例：CONTACT_FORM_RECIPIENT_EMAIL）。Node.js Hosting の UI で設定してください。ハードコードしたり、TODO のプレースホルダーを使ったりしないでください。未設定の場合は安全側に倒して処理を失敗させてください。ユーザーごとの宛先は、匿名のリクエスト本文ではなく、アプリのデータから渡してください。
• ゲートウェイの生のエラーをエンドユーザーに表示しないでください。サーバー側でログに記録し、一般的なエラーメッセージを表示してください。

レシピとヘルパー：email.md。契約ルール：C13。既存の nodemailer コードの移行：email.md#migrating-from-nodemailer。

既存アプリへの適用

ユーザーがすでにプロジェクトを持っている場合（ローカルリポジトリ、zip エクスポート、または Node.js Hosting での実行に失敗したアプリ）は、この手順を使ってください。目標はホスティングとの互換性のみです。新機能、リファクタリング、フレームワークの変更は行いません。

原則

• 製品の機能を追加または削除しないでください。無関係なコードもリファクタリングしないでください。
• 差分は最小限にしてください。アプリのロジックを書き換えるのではなく、package.json（name、version、main、build、start）、リッスン／バインドの行、必要に応じて静的サーバーファイルを優先してください。
• 検出されたフレームワークを維持し、そのスタックに限って examples.md に沿うよう main、scripts.start、scripts.build を調整してください。

適応ワークフロー

contract.md に照らして監査します（9 つのプラットフォーム要件：package.json のフィールド、build／start、PORT、依存関係、環境変数、Vite、zip サイズ、ネットワーク、MySQL）。各項目について、準拠状況を確認し、最小限の修正を適用して、既存の動作をすべて維持します。

コピーして進捗を記録します。

- [ ] Run validator on project root (baseline)
- [ ] Map each error/warning to contract rule (see table below)
- [ ] Apply minimal fix per ID; use framework recipe for script names only
- [ ] Re-run validator until exit 0 (or document warnings if not --strict)
- [ ] install → build → start locally (match lockfile package manager)
- [ ] Pre-upload checklist complete

バリデーター（完了前に必須）：

node scripts/validate-paas.mjs /path/to/project

このスキルディレクトリから実行します（例：npx skills add の実行後、または ~/.cursor/skills/godaddy-nodejs-hosting へのシンボリックリンク作成後）。nodejs-hosting-agent-skill のクローンから実行する場合：npm run validate -- /path/to/project。

症状の詳細：troubleshooting.md。

ID	一般的な最小限の修正
E001	ルートに package.json を追加
E002	レシピに従って scripts.start を追加または修正
E003	start のエントリーパスを修正するか、不足しているファイルを追加
E004	process.env.PORT を使用し、ハードコードされた listen(N) を削除
E005	scripts.build を追加（echo build またはフレームワークのレシピ）
E006	実行時パッケージを dependencies に移動
E007	package.json に name と version を追加
E008	既存のエントリーファイルを指す main を追加
W001	アップロード対象から .env を除外し、環境変数にはホスティング UI を使用
W002	任意：engines.node を追加
W004	デプロイから node_modules を除外（zip または Git）
E009	dependencies に mysql2 を追加
E010	各 DB_* を process.env から読み込む（managed-mysql を参照）
C14	registry=https://registry.npmjs.org/ を記述した .npmrc を作成します。ロックファイルに非公開 URL が含まれている場合は、ロックファイルを削除して再インストールします

特別なケース

• モノレポ（C1）： 適応を始める前に、独自のルート package.json を持つアプリのフォルダーを 1 つ抽出します。ユーザーから依頼されない限り、パッケージをその場で再構成しないでください。
• Next.js の静的エクスポート： 標準の Next レシピを適用する前に、next.config.* で output: 'export' を確認します。nextjs-static-export（next build ＋ Express でエクスポート先ディレクトリを配信）を使用し、next start は使用しないでください。設定内の distDir に合わせます（デフォルトは out/）。ホスティングパターンは Vite／Lovable の静的アプリと同じですが、ビルドには next build を使用します。
• フロントエンドのみ／サーバーなし： vite-react-vue-spa と AI export quick fixes を参照してください。
• 別のホストからの移行： 手順は同じです。PORT、start／build、dependencies、ロックファイルに注目してください。

Replit、Lovable、Bolt のパターンについては、このワークフローを適用した後に AI export quick fixes を参照してください。

新しいアプリと同じ 完了基準（バリデーターが 0、チェックリスト完了、Node.js Hosting で更新できる状態）を満たせば、適応は完了です。

新しいアプリのワークフロー

コピーして進捗を記録します。

- [ ] Detect framework (package.json)
- [ ] Apply recipe from examples.md
- [ ] Add `.npmrc` with `registry=https://registry.npmjs.org/` to project root
- [ ] install && run build (if exists) && run start (npm, pnpm, or yarn — match user's lockfile)
- [ ] node scripts/validate-paas.mjs <project-dir>
- [ ] Pre-upload checklist complete

バリデーターは、既存アプリの適応と同様に実行します。

フレームワークの検出

package.json 内の判定要素	レシピ
依存関係に next がある（標準）	examples.md#nextjs — まず next.config.* を確認
next.config.* に output: 'export' がある	examples.md#nextjs-static-export
依存関係に nuxt がある	examples.md#nuxtjs
@remix-run/node または remix	examples.md#remix
@nestjs/core	examples.md#nestjs
fastify	examples.md#fastify
vite（SPA）	examples.md#vite-react-vue-spa
react-scripts	examples.md#create-react-app
express、koa、hono、またはプレーンな node サーバー	examples.md#express-koa-hono
フロントエンドのみ／不明なエクスポート	examples.md#vite-react-vue-spa（静的サーバー）

既知のフレームワークに対して start コマンドを独自に考案せず、レシピをそのまま使用してください。

AI エクスポートのクイック修正

ソース	修正
Replit	.replit、replit.nix を削除し、ルートに start スクリプトがあることを確認します
Lovable / Bolt	dist/ または build/ 用の Express 静的サーバーを追加し、dependencies に express を追加します
Next.js 静的エクスポート	設定に output: 'export' を指定します。next build はそのまま使用し、distDir（デフォルトは out/）のエクスポート先を配信する Express を追加します（nextjs-static-export）。Vite/Lovable 向けの手順ではありません
package.json がない	start を含めて作成し、インストールを実行して（npm/pnpm/yarn）ロックファイルを生成します
ポートがハードコードされている	process.env.PORT || 3000 を使用します
依存関係のセクションが誤っている	実行時パッケージを dependencies に移動します

Lovable/Bolt で静的ホスティングを行う場合は、vite-react-vue-spa の手順を使用してください。

アップロード前のチェックリスト

• package.json：name、version、main、build、start
• 本番環境の依存関係は dependencies に指定します。node_modules はデプロイしないでください（zip または Git から除外します）
• リスニングには process.env.PORT を使用し、シークレットには process.env を使用します
• デプロイ用成果物を 100 MB 未満にします（zip アップロード）
• ローカルで実行できることを確認します：インストール → ビルド → 起動
• プロジェクトルートに registry=https://registry.npmjs.org/ を指定した .npmrc を配置します。ロックファイル内の URL は公開 npm のものである必要があります（異なる場合はロックファイルを再生成します）
• ロックファイルが存在すること（コミット済み、またはアップロードに含まれていること）。バリデーターの終了コードが 0 であること。.env がないこと
• HTTP/HTTPS のアウトバウンド通信のみを使用します。該当する場合、DB には DB_* と mysql2 を使用します

完了条件

次の条件をすべて満たした場合にのみ、タスクは完了です。

1. プロジェクトディレクトリで validate-paas.mjs が終了コード 0 で終了すること。
2. アップロード前のチェックリストを満たしていること。
3. Node.js Hosting でアプリを公開・更新できることをユーザーに伝えること（UI での Git 同期または zip アップロード）。ユーザーがすでに使用する方法を伝えている場合は、その方法のみを案内します。