2025/09/23 by semikoron
- パッケージをインストール
npm i
- ローカルサーバーを起動
npm run dev
- ローカルサーバーへアクセス http://localhost:5173
- フレームワーク:Vite + React
- ルーティング:react router dom
- グローバル状態管理:Zustand
- サーバー状態管理:swr
- linter:biome
- UI テスト:Storybook
- API テスト:Jest
- CI: github workflow + husky + lint-staged
詳しくはこちら
基本的には issue に自分をアサインしてから作業に取り掛かること。 またその際 project のステータスを to-do から実装中に変更を行うこと。 また作業が終了し、ブランチがマージされた際には issue のステータスを実装完了に変更し、issue を closed にすること。 新しく issue を立てて作業にする時も必ず project の追加を忘れないようにすること。
ブランチの命名規則は以下のようにすること
接頭辞/issue番号-内容-内容
内容はケバブケースを使用し、接頭辞には以下のような内容を使用すること。
| 接頭辞 | 内容 |
|---|---|
| fix | 既存の機能の問題を修正する場合に使用します。 |
| hotfix | 緊急の変更を追加する場合に使用します。 |
| add | 新しいファイルや機能を追加する場合に使用します。 |
| feat | 新しい機能やファイルを追加する場合に使用します。 |
| update | 既存の機能に問題がないが、修正を加えたい場合に使用します。 |
| change | 仕様変更により、既存の機能に修正を加えた場合に使用します。 |
| refactor | コードを修正し、改善する場合に使用します。 |
| improve | コードの改善をする場合に使用します。 |
| disable | 機能を一時的に無効にする場合に使用します。 |
| delete | ファイルを削除する場合や、機能を削除する場合に使用します。 |
| rename | ファイル名を変更する場合に使用します。 |
| move | ファイルを移動する場合に使用します。 |
| upgrade | バージョンをアップグレードする場合に使用します。 |
| revert | 以前のコミットに戻す場合に使用します。 |
| docs | ドキュメントを修正する場合に使用します。 |
| style | コーディングスタイルの修正をする場合に使用します。 |
| perf | コードのパフォーマンスを改善する場合に使用します。 |
| test | テストコードを修正する場合や、テストコードを追加する場合に使用します。 |
| chore | ビルドツールやライブラリで自動生成されたものをコミットする場合や、上記の接頭辞に当てはまらない修正をする場合に使用します。 |
基本何をやったか分かるような内容であれば構わない。 余裕があればブランチ命名規則同様に接頭辞を記載すること。
作品一覧ページ
├── discord 認証ページ
├── 作品投稿ページ
├── 作品編集ページ
├── 作品詳細ページ
└── ユーザーページ
src
├── assets
│ └── react.svg
├── features
│ ├── Header
│ │ ├── index.module.css
│ │ └── index.tsx
│ └── WorkIndex
│ ├── hook
│ ├── index.module.css
│ └── index.tsx
├── pages
│ └── TopPage
│ ├── index.module.css
│ └── index.tsx
├── shared
│ └── ui
│ ├── Card
│ └── Switch
├── types
│ └── work.ts
└── util
└── fetchData.ts
ロゴ、ペイロード画像など配置するディレクトリ バンドルサイズの肥大化につながるので基本的に画像は webp の拡張子にすること
一つの機能としての粒度として切り分けているコンポーネントフォルダ、カスタムフックを用意する場合は今回は features アーキテクチャを採用しているため、features 配下に、/hooks /store などのディレクトリを設けること。feature のコンポーネントのさらに切り分けを行う場合、再利用不可能であると考えられる場合はその feature のフォルダ配下にコンポーネントを作成すること。また再利用可能と考えられる場合は shared ディレクトリに作成すること。
page の構成を記述したファイルを格納しておくディレクトリ。 基本 page で多くの記述は行わず、features の要素を組み合わせ、ページを完成させるようにすること。
使い回しができる ui や type を配置しているディレクトリ
全体で利用できる型の宣言は基本こちらで行うこと、それ以外はそれぞれの作業部分のディレクトリ配下に /type もしくは /store ディレクトリを配置すること
使い回しができる関数を置いておくディレクトリ。名称が分かりにくくなる可能性があるので、まとめられそうな関数があれば、フォルダ、もしくは同じファイル上に記入を行うなどで対策を行うこと。