5.3 KiB
開発への協力方法
これは個人的なフォークなので、基本的には本家 Firefish の開発に協力してもらえればと思います。ただし、最近は本家 Firefish へのマージリクエストのマージが滞りがちですし、本家版にいきなり貢献するのはハードルが高いと思ったりマージしてもらえるか分からないニッチな機能を作ったりした場合にはこのフォークへ貢献していただいてもよいです。
現状、マージリクエストを直接送る方法が無いので patch ファイルまたは別のサイトにフォークしたリポジトリに追加したコミットへの URL を私に送ってください。
開発の方法
環境構築
-
以下のソフトウェアをインストールする
- podman
- podman-compose
- make
- nodejs
- pnpm
- shellcheck
- sea-orm-cli
- cargo
-
コンテナを起動し、PGroonga を有効化する
cd dev make up
-
以下の内容の
.config/default.yml
を作成するurl: http://localhost:3000 port: 3000 db: host: localhost port: 25432 db: firefish_db user: firefish pass: password redis: host: localhost port: 26379
コンテナを作り直すと簡単にデータベースを初期化できます。
cd dev
make
参考にした記事: Firefish 開発環境の準備(バックエンド向け)
実行
make debug
コミット前に行う確認
make pre-commit
コミットメッセージ
コミットメッセージの書き方に厳密な規則はありませんが、私は以下のようにコミットメッセージを書いているのである程度それに則ってもらえると助かります。でも適当で大丈夫です(更新を取り込む際にコミットメッセージが書き換えられる場合もありますが、ご了承ください)。
コミットメッセージは英語で書き、場合によっては冠詞などを適度に省いて短く収めてください。長い説明が必要な場合には、以下の規則で 1 行目にざっくりとしたコミットメッセージを書いてから 2 つ改行して(つまり 1 行空けて)詳細説明を続けてください。
コミットメッセージの頭文字は大文字にせず、動詞から始める場合には現在形を用いてください。例えば、feat: Added xxxxx
とはせずに feat: add xxxxx
としてください。
- 重大な不具合の緊急修正:
hotfix: 不具合の内容
- プログラム自体が起動しなくなったり投稿が一切できなくなるなどの重大な不具合を回避するための更新には
hotfix:
を頭につけます。
- プログラム自体が起動しなくなったり投稿が一切できなくなるなどの重大な不具合を回避するための更新には
- ドキュメントのみの更新:
docs: 更新の概要
- 内容がドキュメントの更新のみの場合、
docs:
を頭につけます。たとえ更新内容が誤字の訂正であったとしてもfix: typo
ではなくdocs: fix typo
とします。
- 内容がドキュメントの更新のみの場合、
- 翻訳の更新:
locale: 更新の概要
locales/
以下のファイルをいじった場合のコミットなどがこれに該当します。
- コンテナイメージに関する更新:
container: 更新の概要
Dockerfile
やdocker-compose.yml
の更新など、Podman/Docker のユーザー以外には一切影響しない更新がこれに該当します。
- Firefish のプログラム本体には変更を加えない更新:
dev: 更新の概要
- アップデートスクリプトや Makefile の更新など、プログラム本体への変更は加えない場合には
dev:
を頭につけます。 packages.json
,packages/
,locales/
に変更を全く加えていないコミットは大体これに該当します。- 開発とは全く関係無い場合には
meta:
を用いてもよいです。
- アップデートスクリプトや Makefile の更新など、プログラム本体への変更は加えない場合には
- 不具合の修正:
fix: 不具合の内容
- 機能の追加:
feat: 更新の概要
- パフォーマンスの向上のための再設計:
perf: 再設計の概要
- Web クライアントの見た目の変更:
style: 更新の概要
- プログラムの再設計:
refactor: 再設計の概要
- その他の雑務:
chore: 更新の概要
- コードのフォーマットや非常に小規模なプログラムの書き換え(一箇所の
||
を??
に書き換えるなど)や依存パッケージの更新がこれに該当します。
- コードのフォーマットや非常に小規模なプログラムの書き換え(一箇所の
更新が本当に小規模な場合には :
の直前に (minor)
を入れても良いです(例: docs (minor): fix typo in README.md
)が、ほとんどの場合にこれは使う必要がありません。
注意事項
データベースのマイグレーションを伴う変更を加える場合にはマイグレーションのファイルを packages/backend/migration-neko
の下に作成し、マイグレーションを打ち消す SQL クエリを neko/revert.sql
の一番上に追記してください。