rollupを利用した、RPGツクールMZのプラグインを快適に書ける仕組み

目次

  1. ざっくりした仕組み
  2. 何が嬉しいのか
  3. どうして今？
  4. 移行後のプラグイン開発がどうなるか
  5. 詳細と実装
    1. yamlからヘッダとパラメータパースコードを生成
    2. rollupで生成したコードと本体を合体させる
    3. cpxでプロジェクトディレクトリにコピー
    4. GitHub Actionsでリリースブランチにpush

RPGツクールMZのプラグインを、新リポジトリへ移行しました。
これでかなり快適にプラグインが書けるようになったと思うので、仕組みを紹介します。

ざっくりした仕組み

プラグインのヘッダコメントに必要な情報をyamlに書いて、そこからヘッダとパラメータパースコードを生成、本体コードとがっちゃんこして最終的なプラグインを生成します。
成果物はmasterブランチのpush後にGitHub Actionsでreleaseブランチへコミットされます。
また、設定したプロジェクトのプラグインディレクトリに対して自動的にコピーする機能も備えています。

何が嬉しいのか

パラメータを書く際に、いちいちツクールエディタ向けのコメントとパラメータのパースコードを書かずに済みます。
プラグインを書くたびにわざわざ書かなければいけないこのボイラープレートを、yamlから自動生成させることができるのです。

効率化できるのはもちろんのこと、一つのyaml設定から書き出すため、片方だけ型を間違った、などという事故が起こらなくなります。1

また、日本語設定と他言語設定を並べて書けるようにもしているので、多言語対応がベタ書きするよりも格段に楽になっています。
ついでに言うと、yamlの編集だけで多言語対応を済ませられるので、コードをガッツリ書く人でなくても翻訳に集中できたりします。
PR出してくれても良いのよ！2

どうして今？

この構成自体は、MVのプラグインが対象であっても可能です。
ヘッダコメントとパラメータパースのコードの自動生成は同様に有効ではあるのですが、成果物の扱いや動作確認の方法について具体的な方法をイメージできないままズルズルとプラグインだけが増えていき、最終的に移行が現実的でないところまで来てしまっていました。

今になってこの構成へ移行した理由は、だいたい以下の理由からです。

  1. 偶然、Ruたんさんのリポジトリの構成を見て、これなら真似できるんではないかと思った
  2. MZは発売から2週間程度しか経っていなかったので、まだMZ向けプラグインが少ない

なお、このうち2は少ない（少ないとは言ってない）状態だったので、移行はそれなりに時間がかかりました。

移行後のプラグイン開発がどうなるか

  1. yarn generate (プラグイン名) でconfig.ymlと本体プラグインファイルを作る
  2. config.ymlの内容を埋めたら、 yarn build:config でヘッダとパラメータパースコードを生成
  3. 必要なら本体からパラメータパースコードをimportしてプラグインのコードを書く
  4. 書き終わったら yarn build
  5. 動作確認したらmasterへpush

既にあるプラグインを編集する際は、 yarn watch を起動しておいて編集しつつ動作確認、なんてこともできます。

個人開発なのでmasterブランチ一本で今のところは大丈夫そうですが、開発用ブランチ切ったりPRを受け付けることを考えると、マージフックでreleaseブランチへのコミットも走らせたほうが良い気がしてきました。
これは必要になった時に試してみましょう。

詳細と実装

yamlからヘッダとパラメータパースコードを生成

生成ロジックはnodejsで割と力技で書いています。
形式が決まっているので、あんまり難しいことはしていません。愚直にめんどくさいコードを書きました。

Ruたんさんのものをほとんどそのままコピーしても動くとは思うのですが、完全に自分用ということで、自分用の設定内容はハードコーディングしてしまい、これまでのプラグインと構成が大きく変わらないようなポリシーで生成できるようにしています。

ここでプラグイン本体を X.js とすると、その横の _build ディレクトリに X_header.js と X_parameters.js が生成されます。

rollupで生成したコードと本体を合体させる

headerとparametersを生成したら、いよいよrollupの出番です。
rollupは複数のjsファイルを一つにまとめてくれる賢いヤツです。
yamlから生成したX_header.js,X_parameter.js,そして本体のX.jsをくっつければ、配布する形式の成果物が出来上がるというわけです。

cpxでプロジェクトディレクトリにコピー

別にcpxでなくても、fsのcopyFileでも良いと思います。
設定したプロジェクトで動作確認できるよう、プロジェクトのディレクトリにコピーすることができます。

watchモードでnodeスクリプトを起動すれば、プラグインの変更を検知して自動でプロジェクトディレクトリにも同期してくれます。

GitHub Actionsでリリースブランチにpush

GitHub Actionsは.github/workflows下にyamlを書いて定義します。
masterブランチのpush時に、成果物をreleaseブランチに入れてpushするだけの単純なヤツです。

Ruたんさんの構成ではgh-pagesに上げる方式でしたが、gh-pagesは将来プラグインの解説ページを作る時に使おうかなと考えているので、releaseブランチにアップする構成にしました。

  1. エディタ設定側ではboolean型なのに、パースのコードはnumber型になってしまっている、みたいなケースは割と良く見かける。
  2. まあ、まずCONTRIBUTING.mdに英訳をつけるのが先ではあるが。