本記事について
この記事は CoreBluetoothForUnity Advent Calendar 2023 の9日目の記事です。
CoreBluetoothForUnity の開発リポジトリのディレクトリ構造がなぜ現状のようになっているかについて紹介します。
前提
本ディレクトリ構成は hecomi さんの記事、構造を非常に参考にして作成しています。
公式カスタムパッケージの作成方法
パッケージ作成方針
私のパッケージ作成方針は以下のようにしました。
- ローカルパッケージとして作成 (Packages以下に配置)
- Native Plugin は同じリポジトリで開発する
- ドキュメントも同じリポジトリに含める
- Samples は開発しやすくするために Assets 以下に配置する
- インストール方法は複数対応しなくても構わない。
この方針にした理由を以下に記載します。
ローカルパッケージとして作成する理由
公式ドキュメントより、パッケージの作成方法は 埋め込みパッケージ と ローカルパッケージ の2種類があります。
ローカルパッケージを選択した深い理由はありません。
ただ、パッケージは Packages 以下に入ってた方が自然だと思ったためローカルパッケージにしています。
Native Plugin は同じリポジトリで開発する理由
メリット・デメリット以下のように考えています。
- メリット
- リポジトリ切り替える手間がなく楽
- 変更履歴が一元管理できる。
- デメリット
- リポジトリの肥大化
- コミットログが混ざって汚くなる。
メリットの方が大きいと考え、同じリポジトリで開発することにしました。
この判断は正しかったと思っています。
プラグインの配置場所は hecomi さんの以下のリポジトリを真似しました。
ドキュメントも同じリポジトリに含める理由
ドキュメントというか docs フォルダです。
ドキュメントのフォルダ名はなんでもよかったのですが、UniTask や Unity 公式のリポジトリで docs という名前が使われていたためそれに合わせました。
GitHub Pages でリポジトリ内のフォルダを公開する設定にする場合には、
静的サイトでコミットログ汚くなるため別リポジトリにしてもいいかなと思っていました。
幸いCI で静的サイトをビルドし、GitHub Pages で公開する仕組みにできたため、変更差分はほとんど発生しなくなりました。
そのため docs には生成に必要なファイルのみを配置しています。
これについては別の記事に詳しく書こうと思っています。
インストール方法は複数対応していない。
単純に手間削減のためと、依存関係がどうなるかよくわかっていないためです。
CoreBluetoothForUnity は部分的に別パッケージに分離することを考えています。
従って、それらをまとめてインストールできる方法が望ましいです。
で、Git だとわからないけど、Scoped Registryならできそうということで npmjs で公開しています。
結論
以上を踏まえて、以下のようなディレクトリ構成にしました。
<Repository>
├── Assets
│ └── CoreBluetooth
│ └── Samples
│ ├── 01_LightControl
│ └── ...
├── Packages
│ └── com.github.teach310.corebluetoothforunity
│ ├── Runtime
│ ├── package.json
│ └── ...
├── docs
├── Plugins
│ └── CoreBluetoothForUnity
├── ...
おわりに
本記事では CoreBluetoothForUnity のディレクトリ構造について紹介しました。
私はこのディレクトリ構造に辿りつくまでに調査に何時間か使ってしまったためこの記事が誰かのライブラリ作成の時間につながればいいなと思います！