Zenn
🛣️

OSSへの道。Difyのコントリビュートガイドを読んで、PRを出す。

2024/09/09に公開
OSS
Dify
tech

本記事の対象者

OSSへのコントリビュート、してみたいけど怖くてできない。やり方が分からない。
そんな方に読んでほしい記事です。

※一般的なOSSへのコミットと共通するところは多いですが、今回はあくまでもDifyへのコミットを前提としています。

本記事で説明すること・しないこと

説明すること

  • Difyのコントリビュートガイドの説明
  • DifyへPull Requestを出す方法

説明しないこと

  • Pythonの書き方・GitやGitHubの使い方
  • Difyのソースコードの内容

0. コントリビュートガイドを読む

https://github.com/langgenius/dify/blob/main/CONTRIBUTING_JA.md

まずコントリビュートガイドを読みます。
多くのOSSでは必ずこのガイドがどこかにあるはずです。（無い場合もありますが、大抵はREADMEに書いてあるなど、すぐに見つかる場所にあると思います）

Difyはありがたいことに日本語翻訳版があるので、今回はそちら（CONTRIBUTING_JA.md）を読みましょう。

ライセンス、規約、行動規範を確認

事前に目を通しておきます。
Difyの場合は英語ですが翻訳すればサクッと読めるボリュームなので、トラブルになる前によく読んでおいてください。

(新しい)機能リクエストをしたい場合

新しい機能を提案したい場合は、なるべく情報を詳細に書いてissueを作成します。
既存のissueの修正をしたい場合は必ずそのissueにコメントし、アサインされてから取り組むようにしてください。
（アサイン前に修正すると、努力が水の泡になる可能性があります）

バグレポート、パフォーマンスの最適化、誤字の修正などを行いたい場合

すぐに修正を始めてOKです。

最初はこちらから始めるのがいいと思います。本記事でもこちらの修正をする前提で進めていきます。
（IDEなどで構文解析すると、非推奨の書き方などリファクタできる場所が山のように出てきます）

1. Forkする

DifyリポジトリのForkボタンを押して、自分のリポジトリへコピー?します。

2. Cloneして修正する

git clone git@github.com:<自分のアカウント>/dify.git

ローカルに環境を構築し、いよいよここから修正開始です。
（ローカル環境構築は別途記事にしたいと思っています）

自分はブランチを切って開発をしています。

ディレクトリ構成（バックエンド）

以下の構成となっています。

  • 言語: Python
  • フレームワーク: Flask
  • ORM: SQLAlchemy
  • タスクキュー: Celery
[api/]
├── constants             // コードベース全体で使用される定数設定
├── controllers           // APIルート定義とリクエスト処理ロジック
├── core                  // アプリケーションの中核的な管理、モデル統合、およびツール
├── docker                // Dockerおよびコンテナ関連の設定
├── events                // イベントのハンドリングと処理
├── extensions            // 第三者のフレームワーク/プラットフォームとの拡張
├── fields                // シリアライゼーション/マーシャリング用のフィールド定義
├── libs                  // 再利用可能なライブラリとヘルパー
├── migrations            // データベースマイグレーションスクリプト
├── models                // データベースモデルとスキーマ定義
├── services              // ビジネスロジックの定義
├── storage               // 秘密鍵の保存
├── tasks                 // 非同期タスクとバックグラウンドジョブの処理
└── tests                 // テスト関連のファイル

※本情報はCONTRIBUTING_JA.mdに記載があります。

ディレクトリ構成（フロントエンド）

  • 言語: TypeScript
  • フレームワーク: Next.js
  • スタイリング: Tailwind CSS
[web/]
├── app                   // レイアウト、ページ、コンポーネント
│   ├── (commonLayout)    // アプリ全体で共通のレイアウト
│   ├── (shareLayout)     // トークン特有のセッションで共有されるレイアウト
│   ├── activate          // アクティベートページ
│   ├── components        // ページやレイアウトで共有されるコンポーネント
│   ├── install           // インストールページ
│   ├── signin            // サインインページ
│   └── styles            // グローバルに共有されるスタイル
├── assets                // 静的アセット
├── bin                   // ビルドステップで実行されるスクリプト
├── config                // 調整可能な設定とオプション
├── context               // アプリの異なる部分で使用される共有コンテキスト
├── dictionaries          // 言語別の翻訳ファイル
├── docker                // コンテナ設定
├── hooks                 // 再利用可能なフック
├── i18n                  // 国際化設定
├── models                // データモデルとAPIレスポンスの形状を記述
├── public                // ファビコンなどのメタアセット
├── service               // APIアクションの形状を指定
├── test
├── types                 // 関数のパラメータと戻り値の記述
└── utils                 // 共有ユーティリティ関数

※本情報はCONTRIBUTING_JA.mdに記載があります。

3. Pull Requestを出す

修正が完了したらコミットをし、自分のリモートブランチにpushします。
この後はPRを出すだけです。
※基本的にはlanggenius:mainブランチへPRを出せばOKです。

PRを作成すると、自動で以下のようなフォーマットが出てくるので、チェックリストの項目を確認してチェックをつけます。
※こちらは日本語に翻訳したものです。本来は全て英語で記述します。

英語版のPR画像はこちら

PRを出すと、botがPRの内容を見て自動でラベルをつけてくれます。
後はレビューされるのを待ちます（簡単なものであれば24時間以内にマージされますが、検証が必要なものは数日かかるようです）

マージされたら完了です！

おまけ

Contributorは執筆時点で400人越えですが、READMEに表示されるのは上位100名です。
TOPに表示されたい場合はより多くの貢献が必要です。

最後まで読んでいただきありがとうございます。

Discussion