はじめに
コンポーネント開発を行う上で資産の共通化をしたいと思うのは自然なことだと思います。
GitLab上でどのような管理することでこれを実現できるのかを考えましたので記事にしたいと思います。
コンポーネント用のプロジェクト
例としてcommon_component プロジェクトであったとします。
GitLab上にcommon_componentを立ち上げ、その中にコンポーネント開発を行っていきます。 Atomic Designで作成するプロジェクトであれば以下のような形でしょうか
root/
- atoms
- molecules
- organism
- template
pageは個別のプロジェクトでの開となると考えていますが、必要であれば追加すればよいと思います。
また、ここにリファレンス集がおかれるとよいでしょう。 目次を作成し、マークダウン形式でリファレンスを作成するなど良いかと思います。
ここでポイントがあります。
①テストはバージョンごとにコンポーネント単位で完結させておく
②命名規則、公開関数、通知などは画一的に行う。
③プロジェクトの依存はルールを設ける
ことです。
①テストはバージョンごとにコンポーネント単位で完結させておく
これは普通何かしらのライブラリを使用する際に、ライブラリ内部のテストはしませんよね? というだけになります。
単純にフォーカスアウトしたらカンマ区切りにするようなコンポーネントであれば、それを保証しましょうというだけです。
このテストは利用者側のプロジェクトで行われるべきではないという主張になります。
②命名規則、公開関数、通知などは画一的に行う
これも一般的なお話しです。
が、コンポーネント・開発において社内にその地位が確立されていればよいのですが、有志による活動になってしまう企業様もあるのではないでしょうか? こういった場合に有志による活動に対する画一的なルールが設けられているというのは少ないと思われ、個人の量によるところが強くなってしまうと思います。
このような効率化の為の活動において後々属人化につながっていきますので、気を付けるべきことであると考えます。
③プロジェクトへの依存はルールを設ける
これは私も頭を悩ませたのですが、できればプロジェクト(共通関数を定義しているなど)はあまり設けたくありません。
が、utilityな関数はコンポーネントとは別に定義したい関係上、複数同じような関数を設けることはしたくなく致し方なく依存を設けました。
ルールといっても、依存しているプロジェクトが存在していなければエラーが出るのですぐ気づくようなものですが、ドキュメントに記載するなどの措置で我慢しています。
場合によっては構成毎のブランチでもいいかもしれません。
が、マージが・・・というところがあり今のところはあまり取り組みたくない方です。
プロジェクト構成
上記、「他プロジェクト・・・」 の例も含めて以下の構成管理を案といたします。
例)
project
- common_component (submodule)
- atoms
- XXinput. vue (utilの関数を使用したい)
- util (submodule)
- common_function, ts
- 他プロジェクトファイル
おまけ submoduleの追加・ submoduleを含んだプロジェクトのclone
プロジェクトへのsubmoduleの追加
git submodule add http://iccgit01/XXXX. git 追加したいディレクトリ
submoduleを含んだプロジェクトのcloneはリカーシブに行う必要があります。
git clone --recursive http://iccgit01/XXXXXXXXX. git