Hatcherへの貢献

Hatcherへの貢献にご興味をお持ちいただき、ありがとうございます！このガイドは、プロジェクトへの貢献を始めるのに役立ちます。

行動規範

このプロジェクトに参加することで、私たちの行動規範を遵守することに同意したものとみなします。貢献する前にお読みください。

はじめに

開発環境のセットアップ

1. フォークとクローン

   git clone https://github.com/your-username/dx-engine.git
   cd dx-engine

2. 依存関係のインストール

   pnpm install

3. 開発サーバーの起動

   pnpm dev

プロジェクト構造

dx-engine/
├── apps/
│   ├── electron/          # メインElectronプロセス
│   ├── web/              # レンダラープロセス (Vue.js)
│   ├── preload/          # プリロードスクリプト
│   └── docs/             # VitePress ドキュメント
├── universal/
│   ├── vite-plugin/      # カスタムViteプラグイン
│   └── puppeteer-google-translate/
└── scripts/              # ビルドと開発スクリプト

貢献の方法

バグ報告

バグを報告する際は、以下を含めてください：

• 明確な説明：何が起こったか vs. 何を期待していたか
• 再現手順：問題を再現するための詳細な手順
• 環境：OS、Node.jsバージョン、pnpmバージョン
• スクリーンショット：該当する場合、視覚的証拠を含める

イシューを作成する際は、バグ報告テンプレートを使用してください。

機能リクエスト

機能リクエストを歓迎します！以下を含めてください：

• 使用例：なぜこの機能が必要なのか？
• 提案された解決策：どのように動作すべきか？
• 代替案：他にどのようなアプローチを検討しましたか？

機能リクエストテンプレートを使用してください。

コード貢献

開始前に

1. 既存のイシューを確認：関連するイシューや機能リクエストを探す
2. 重要な変更を議論：重要な変更を議論するためのイシューを開く
3. 小さく始める：小さく焦点を絞った貢献から始める

開発ワークフロー

1. ブランチの作成

   git checkout -b feature/your-feature-name

2. 変更を行う

   • コーディング標準に従う（下記参照）
   • 新機能のテストを書く
   • 必要に応じてドキュメントを更新

3. 変更をテスト

   pnpm build
   pnpm test

4. 変更をコミット

   git commit -m "feat: add amazing new feature"

   Conventional Commits形式に従います。

5. プッシュとPR作成

   git push origin feature/your-feature-name

コーディング標準

Hatcherは、プロジェクト全体で一貫性、保守性、高品質なコードを確保するために厳格なコーディング標準に従います。

📋 完全なコーディング標準ガイド

クイックリファレンス

TypeScript

• 厳密モードを有効にしたTypeScriptをすべての新しいコードで使用
• オブジェクト形状にはtypeよりinterfaceを優先
• 変数と関数に意味のある説明的な名前を使用
• すべてのパブリックAPIにJSDocコメントを含める

Vue.js

• <script setup>構文でComposition APIを使用
• TypeScriptインターフェースでpropsとemitsを定義
• 再利用可能なロジックにはcomposablesを優先
• 単一ファイルコンポーネント構造に従う：script → template → style

スタイリング

• コンポーネント固有のCSSにはスコープ付きスタイルを使用
• クラス命名にBEM手法を従う
• テーマにはCSSカスタムプロパティを使用
• レイアウトにはflexboxとCSS Gridを優先

Git規約

• Conventional Commits形式に従う
• 説明的なブランチ名を使用：feature/、fix/、docs/、refactor/
• コミットをアトミックに保ち、単一の変更に焦点を当てる

コード品質ツール

標準を強制するために自動化ツールを使用：

# コードスタイル問題をlintして修正
pnpm lint:fix

# 型チェック
pnpm typecheck

# すべてのテストを実行
pnpm test

# コードをフォーマット
pnpm format

プリコミットフック

Huskyは各コミット前に自動チェックを実行：

• コード品質のESLint
• TypeScriptコンパイル
• フォーマットのPrettier
• クリティカルパスの単体テスト

詳細なガイドライン、例、ベストプラクティスについては、コーディング標準ドキュメントを参照してください。

ドキュメント

ドキュメントの種類

• コードコメント：複雑なロジックを説明
• READMEファイル：概要とセットアップ手順
• APIドキュメント：パブリックインターフェースを文書化
• ユーザーガイド：エンドユーザー向けのハウツーガイド

執筆ガイドライン

• 明確で簡潔な言語を使用
• コード例を含める
• コード変更に合わせてドキュメントを最新に保つ
• すべてのコード例をテスト

プルリクエストプロセス

提出前

• [ ] コードがプロジェクト標準に従っている
• [ ] テストがローカルで合格
• [ ] ドキュメントが更新されている
• [ ] 変更が焦点を絞ってアトミック

PR説明テンプレート

## 説明

変更の簡潔な説明

## 変更の種類

- [ ] バグ修正
- [ ] 新機能
- [ ] 破壊的変更
- [ ] ドキュメント更新

## テスト

- [ ] 単体テストが追加/更新された
- [ ] 統合テストが追加/更新された
- [ ] 手動テストが完了

## スクリーンショット（該当する場合）

UI変更の前後のスクリーンショットを含める

レビュープロセス

1. 自動チェック：CI/CDが通過する必要がある
2. コードレビュー：少なくとも1人のメンテナーのレビュー
3. テスト：開発環境で変更がテストされる
4. ドキュメント：ドキュメントが更新されていることを確認
5. マージ：承認されたPRをスカッシュしてマージ

リリースプロセス

バージョニング

セマンティックバージョニングに従います：

• MAJOR：破壊的変更
• MINOR：新機能（後方互換）
• PATCH：バグ修正（後方互換）

リリースワークフロー

1. 機能フリーズ：新機能の受け入れを停止
2. テスト：包括的なテストフェーズ
3. ドキュメント：変更ログとドキュメントを更新
4. リリース：タグ付きリリースを作成
5. 発表：コミュニティに変更を伝える

コミュニティ

コミュニケーションチャンネル

• GitHub Issues：バグ報告と機能リクエスト
• GitHub Discussions：一般的な質問とアイデア
• Discord：コミュニティとのリアルタイムチャット
• Twitter：@HatcherDXをフォローして更新情報を入手

コミュニティガイドライン

• 敬意を払う：すべての人を尊重して扱う
• 建設的である：問題ではなく解決策に焦点を当てる
• 忍耐強くある：私たちは皆ボランティアであることを忘れない
• 助けになる：知識を共有し、他の人を助ける

認識

すべての貢献を感謝します！貢献者は以下で認識されます：

• CONTRIBUTORS.md：すべてのプロジェクト貢献者のリスト
• リリースノート：主要な貢献がハイライト
• ソーシャルメディア：コミュニティ貢献を特集

開発リソース

有用なリンク

• Vue.js ドキュメント
• Electron ドキュメント
• TypeScript ハンドブック
• Vite ドキュメント

開発ツール

• VS Code：VueとTypeScript拡張機能を備えた推奨エディター
• Vue DevTools：Vueアプリケーションのデバッグ用ブラウザー拡張機能
• Electron DevTools：組み込みデバッグツール

質問？

貢献について質問がある場合：

1. 既存のGitHub Discussionsを確認
2. Discordコミュニティに参加
3. 新しいディスカッションまたはイシューを作成

Hatcherへの貢献をありがとうございます！一緒に、AI支援開発の未来を構築しています。