https://kxn4t.hatenablog.com/entry/2025/04/20/174352

この前、作ったエディタ拡張をVPMリポジトリで配布するまでをやってみました。

kxn4t.hatenablog.com

やってみて、まぁよく分からんなと思ったところがあったので、備忘録がてらちょっと詳しめに書き残しておこうと思います。

記事メンテナンス日：2025/04/20

配布までの全体像

VPMリポジトリでの配布プロセスは、大きく以下の流れで進みます。

個人的には先にリポジトリ作って、それをUnityのPackages配下にCloneしてから開発するほうが楽だと感じているのでこの流れで書いてます。すでに何かしらがあるところにCloneしたりしようとすると色々めんどいので…。

GitHubでパッケージリポジトリの作成
- 開発用のGitHubリポジトリを作成
- ローカル環境（UnityのPackages配下）にClone
- 基本的なフォルダ構造の作成
パッケージの開発と準備
- エディタ拡張の開発
- Assembly Definition (asmdef)ファイルの作成
- package.jsonの設定
パッケージのリリース
- ソースコードのCommitとPush
- バージョンタグの作成と準備
- GitHub Releaseの作成
VPMリポジトリの構築
- リポジトリ用の別GitHubリポジトリの作成
- source.jsonファイルの設定
- GitHub Pagesでの公開
VCCで動作確認＆ユーザー配布
- VCCでのテスト
- ユーザーに配布
- バージョン更新を行う

この流れを理解することで、エディタ拡張の配布がスムーズに進むはずです。特に重要なのは、パッケージ本体を含むリポジトリと、VPMカタログとして機能するリポジトリが分かれていることを認識することだと思います。

VPM配布のメリット

Unity拡張をVPMパッケージとして配布する主なメリットは以下の通りです。

簡単にインストールできる: ユーザーはVRChat Creator Companion（VCC）を使って数クリックでインストール可能
自動バージョン管理: 新しいバージョンがリリースされるとユーザーに通知され、ワンクリックでアップデート可能
依存関係の自動解決: 必要な他のパッケージも自動的にインストール
プロジェクト管理の簡素化: VCCがプロジェクト全体を管理するため、ユーザーはより簡単に環境を構築可能

VRChatユーザーはすでにVCC（ALCOM）を使い慣れているため、同じワークフローでツールをインストールできることで、導入の障壁が大幅に下がるはずです。また、開発者側としても更新配布が簡単にできるので、継続的な改善がしやすくなります。

前提知識

前提知識として、公式ドキュメントは軽く目を通しておくといいと思います。

パッケージとして公開するには、各々のパッケージ用のpackage.jsonとそれを取りまとめるVPMカタログ用のjsonの2つを作ることになる感じです。

1. GitHubでパッケージリポジトリの作成

リポジトリの作成

リポジトリを作る際、LICENSEは必ず選んで含むようにします。あとから追加するの面倒ですからね。
ついでに、READMEも作って、.gitignoreもUnityを選んどくといい気がしています。

ローカル環境へのClone

リポジトリを作成したら、開発用のUnityプロジェクトなり任意のプロジェクトのPackages配下にCloneして開発を始めます。

cd Documents/UnityProjects/MyUnityProject/Packages
git clone <リポジトリのURL> <パッケージ名>

# 例
# git clone git@github.com:kxn4t/kanameliser-editor-plus.git net.kanameliser.editor-plus

パッケージ名ですが、パッケージの命名に従い、逆ドメイン名表記で命名します。

自分の場合は、kanameliser.netドメインを持っているので、net.kanameliser.editor-plusとしました。

2. パッケージの開発と準備

GitHubリポジトリをCloneしたら、必要なファイルやフォルダを作成していきます。

基本的なフォルダ構造

VPMパッケージとして配布するためには、特定のフォルダ構造が必要です。基本的な構造は以下のようになります。

MyPackage/
├── package.json
├── README.md
├── LICENSE.md
├── CHANGELOG.md（任意）
├── Editor/
│   ├── MyDomain.MyPackage.Editor.asmdef
│   └── [エディタスクリプト]
└── Runtime/
     ├── MyDomain.MyPackage.asmdef
     └── [ランタイムスクリプト]

エディタ拡張のみを含むパッケージの場合は、Runtimeフォルダは不要です。各フォルダの役割は以下の通りです。

Editor: エディタ専用のスクリプトを配置
Runtime: 実行時に必要なスクリプトを配置（エディタ拡張のみなら不要）

Assembly Definition (asmdef)ファイルの設定

Assembly Definition（asmdef）ファイルは、パッケージのスクリプトをどのように扱うかを定義します。

Unityでは、スクリプトをコンパイルする際に「アセンブリ（DLL）」にまとめています。デフォルトだとプロジェクト全体が1つのアセンブリにまとまってしまうため、

コンパイル時間が増える
名前空間の衝突リスクがある
外部パッケージへの参照管理が難しい

などの課題があります。

そこで「Assembly Definition File（.asmdef）」を使うことで、スクリプトを明示的に分割・管理できるようになります。とClaudeくんが説明してくれました。

エディタ拡張の場合、Editorフォルダ内にasmdefファイルを配置し、以下のように設定します：

{
    "name": "MyDomain.MyPackage.Editor",
    "rootNamespace": "",
    "references": [],
    "includePlatforms": [
        "Editor"
    ],
    "excludePlatforms": [],
    "allowUnsafeCode": false,
    "overrideReferences": false,
    "precompiledReferences": [],
    "autoReferenced": false,
    "defineConstraints": [],
    "versionDefines": [],
    "noEngineReferences": false
}

他のパッケージへの依存がある場合は、references配列に該当のパッケージ.asmdefのnameを追加します。

自分の場合はKanameliser.EditorPlus.Editor.asmdefとして、こんな感じになりました。

{
    "name": "Kanameliser.EditorPlus.Editor",
    "rootNamespace": "",
    "references": [],
    "includePlatforms": [
        "Editor"
    ],
    "excludePlatforms": [],
    "allowUnsafeCode": false,
    "overrideReferences": false,
    "precompiledReferences": [],
    "autoReferenced": false,
    "defineConstraints": [],
    "versionDefines": [],
    "noEngineReferences": false
}

package.jsonの作成

VPMパッケージの心臓部とも言えるのがpackage.jsonファイルです。このファイルにパッケージの情報や依存関係を定義します。

この内容です。

例としてはこんな感じです。

{
    "name": "com.mycompany.mypackage",
    "displayName": "My Package",
    "version": "1.0.0",
    "unity": "2022.3",
    "description": "いい感じの説明",
    "author": {
        "name": "自分の名前",
        "url": "https://github.com/myusername"
    },
    "license": "MIT",
    "licenseUrl": "https://github.com/myusername/mypackage/blob/main/LICENSE",
    "changelogUrl": "https://github.com/myusername/mypackage/blob/main/CHANGELOG.md",
    "vpmDependencies": {
        "com.vrchat.avatars": "^3.5.0"
    },
}

各項目の意味と設定について説明します：

name: パッケージの識別子。逆ドメイン表記を使用
displayName: VCCで表示される名前
version: バージョン番号（セマンティックバージョニング形式）
unity: 対応するUnityの最小バージョン
description: パッケージの簡単な説明
author: 作者情報
license: ライセンス情報
licenseUrl: ライセンスのURL
changelogUrl: 変更履歴のURL
vpmDependencies: 依存するVPMパッケージとバージョン

特に重要なのは以下の項目です：

name: 必ず逆ドメイン表記を使用し、一意の名前をつけましょう
version: セマンティックバージョニング（x.y.z）を守りましょう
- x: 互換性を破壊する変更（メジャー）
- y: 後方互換性のある機能追加（マイナー）
- z: バグ修正（パッチ）
vpmDependencies: 依存関係を正確に指定
- 具体的な指定方法はGitHub - npm/node-semver: The semver parser for node (the one npm uses)参照

自分の場合はこんな感じになりました。

{
  "name": "net.kanameliser.editor-plus",
  "version": "0.1.1",
  "displayName": "Kanameliser Editor Plus",
  "description": "A small set of useful Unity & VRChat editor extensions by kxn4t",
  "unity": "2022.3",
  "author": {
    "name": "kxn4t",
    "url": "https://github.com/kxn4t"
  },
  "license": "MIT",
  "licenseUrl": "https://github.com/kxn4t/kanameliser-editor-plus/blob/main/LICENSE",
  "vpmDependencies": {}
}

changelogUrlについて、ALCOMでは以前から機能していましたが、VCCでも最近表示されるようになったため、設定することをおすすめします。
（といいつつ、自分は書けていないのですが…。）

もう少し詳しい説明が必要な方はlilさんの記事を参照してください。

【開発者向け】自作物をVPM・VCC対応する方法

3. パッケージのリリース

パッケージの開発が完了したら、GitHubでリリースを作成し、VPMリポジトリから参照できるようにします。

ソースコードのCommitとPush

最後にあらためてUnityで開発中のパッケージが入っているプロジェクトを開き、.metaファイルが生成されていることを確認します。

このように、.gitignoreを除いてすべてのファイル、フォルダで.metaファイルが作成されていることが確認できたら、すべてCommitしPushします。

MyPackage/
├── package.json
├── package.json.meta
├── README.md
├── README.md.meta
├── LICENSE.md
├── LICENSE.md.meta
├── CHANGELOG.md（任意）
├── CHANGELOG.md.meta（任意）
├── Editor/
│   ├── MyDomain.MyPackage.Editor.asmdef
│   ├── MyDomain.MyPackage.Editor.asmdef.meta
│   └── [エディタスクリプト]
├── Editor.meta

GitHub Actionsでビルドできるようにする

こんな感じで.github/workflows/release.ymlを作成し、ビルドからリリースまでをボタンポチで終わるようにします。

kanameliser-editor-plus/.github/workflows/release.yml at main · kxn4t/kanameliser-editor-plus · GitHub

付き合いのあるAzukimochiさんとkb10uyさんの LightLimitChangerやZatoolsのワークフローを参考にさせていただきました。

違いとして、action gh-releaseのdraft: true、generate_release_notes: trueを追加し、リリース前にドラフトとして作成されるようにし、自動的にリリースノートができるようにしてみました。
こうするとリリース前にリリースノートがPRから自動生成され、ドラフトとして作成されるので、実際にリリースする前に修正が可能です。

package.jsonのバージョン設定とバージョンタグの作成

リリースを行うにあたって、まずはpackage.jsonのversionをリリースするバージョンを設定します。セマンティックバージョニングに従い、最初のリリースなら1.0.0か、開発中なら0.1.0でよいでしょう。

一通りCommitしてリリース準備ができたら、リリース管理のためにバージョンタグを作成します。タグ名はvprefixを付けることが一般的です（例：v1.0.0）。

GitHub Actionsでリリース

タグをPushしたら、GitHub Actionsでワークフローを動かし、リリースします。

例として挙げているrelease.ymlを動かす場合はこんな感じです。

リポジトリのページで「Actions」タブを開く
作ったワークフローのページを開き、「Run workflow」を実行
リポジトリの「Releases」ページを開き、できているドラフトを開く
リリースノートを編集（変更内容や新機能などを記載）
「Publish release」をクリック

リリースを公開すると、GitHubは自動的にソースコードのZIPファイルを生成します。このZIPファイルのURLが、次のステップで作成するVPMリポジトリから参照されることになります。

4. VPMリポジトリの構築

リリースが終わって、VPMリポジトリ（カタログ）を作成して、パッケージをVCCから利用できるようにします。
いわゆるlistingページを作ります。

パッケージとVPMリポジトリの関係

まず理解すべきポイントとして、パッケージ本体のリポジトリと、VPMリポジトリ（カタログ）は異なる役割を持つ別々のリポジトリだということです。

パッケージリポジトリ: 実際のコード、package.jsonなどが含まれる（実装）
VPMリポジトリ: 複数のパッケージ情報とダウンロードURLが含まれるカタログ（配布）

VCCはこのカタログを元にパッケージを見つけてインストールできるようになります。

template-package-listingの活用

VRChatが提供するtemplate-package-listingを利用すると、source.jsonを編集するだけで非常に簡単にVPMリポジトリを構築できます。

template-package-listingをテンプレートとして新しいリポジトリを作成
- 「Use this template」→「Create a new repository」を選択
- リポジトリ名は分かりやすく（例：vpm-repository）
新しく作成したリポジトリのsource.jsonを編集して、パッケージ等の情報を設定
GitHub Pagesを有効化：
- リポジトリの「Settings」→「Pages」を開く
- ソースを「GitHub Actions」に設定
GitHub Actionsのワークフローを実行すると、Webサイトがビルドされ公開される