1. 最初に
Firefoxの機能拡張を作って addons.mozilla.org に登録するまでのプロセスを一通りやってみたので、経験したことを個人的に残しておく。技術的な内容はほとんどないです。機能拡張の内容については書きません。
2. 作ったもの
これです
3. 開発のしかた
3.1. 段取り
こんな感じで進めた。機能拡張の内容にもよるけど、私の場合は 6 以降で 1 週間ほどかけた。
- 基本的な勉強する
- ガリガリ機能を作る。
- ひととおり機能を実装し終えたら、アドオン削除、再度追加して、スムーズに利用開始できるよう細かく作り込む。
- 多言語対応する
- Linter をかける
- リポジトリにアップロードする
- 周辺のものを作る
- ウェブサイト
- 利用者向けのドキュメント
- サポート用のメールアドレス
- イシュートラッカー
- ライセンスの選択
- AMO 申請用の各種素材(各種説明文、スクリーンショットなど)
- パッケージ化してバリデータのチェックを受ける
- AMO(addons.mozilla.org の略称)の審査を申請
- 機能拡張として公開
3.2. 各段階の細かなメモ
1. 基本的な勉強
だいたいここを見るとできる。
自分の場合は「始めましょう」の「拡張機能とは何か？」〜「2つめの拡張機能」まで順番にやって、あとはゴリゴリ自分のを書いていった感じ。
現時点(2023年4月時点)では、Manifest のバージョンは 2 で進めたほうがいい。理由は AMO で公開する場合の推奨が 2 だから。Firefox が Manifest v3 をサポートし始めたのが version 109(2023年1月) からでまだ日が浅く、過去のバージョンを使用しているユーザに配慮するため、というのがその理由。一方 Chrome では Manifest v3 の必須化＋Manifest v2 のサポート終了を 2024 年に予定していて、かつその予定も今の所流動的、という状況。Extension を両ブラウザ対応にしようとすると微妙な時期なのかもしれない。
v2 と v3 では API に少し差異がある。具体的にはコンテキストメニューの呼び出し方とか、外部 API の呼び出し制限や、manifest.json の書き方など。
私の場合は最初何も考えず v3 で作り始めて、最終段の AMO バリデータのチェックでひっかかり、v2 対応に修正した。
2~3. 主要機能の開発~作り込み
開発時のハマりとしては、extension から外部の API を呼び出すにはバックグラウンドスクリプトから行ったほうが自由度が高く、Injected content script から行おうとすると、コンテンツの提供元が強制する Content Security Policy の制約を受けるという点。詳細は各自調べてほしいが、ざっくり言うと、コンテンツ提供元がコンテンツ内のスクリプトから呼び出し可能な宛先に制約を設けることができる機能。
Extension 側としてはコンテンツ提供元の制約に縛られるのはしんどいので、バックグラウンドスクリプト側でなんとかする、という対応になる。
その場合は以下のような4段階の処理を行うことになる。まあこれはこういうもんだと思ってやるしかない。
- コンテンツ側で変更したいことを抽出する
- それをバックグラウンドスクリプト側に送信する
- バックグラウンドスクリプト側で受信し、処理する
- 処理結果をコンテンツスクリプト側に返信する
一通り機能を作り終えたら、「アドオン削除〜再度インストール」しながら機能の漏れを埋める部分を作り込む。このあたりから主たる目的から外れ始めるので開発側としては面白くなくなり始めるんだけど、未来の自分も含めて快適に使っていただくためにがんばる。
4. 多言語対応する
WebExtension は i18n 対応がビルトインされているので、それを使って少なくとも英語には対応しておくようにする。AMO に申請するときレビュアーは外国人なので、日本語で書いてあると何が何やらわからんので。今回の場合は日本語と英語に対応した。レビュアーからしたら英語もよくできない人から後出しでいろいろ書かれるよりも、最初から全部英語にしておいたほうが心理的なハードルは低いと思う。
5. Linter をかける
最終的にレビュアーにレビューしてもらうコードなので、マナーとして Linter は必ずかけておく。ESLint のデフォルトのチェックに加えて、Code Complexity のチェックもしておいたほうがいい。これはコードの循環複雑度をチェックするもので、要するに多段 for とか、多段 if とかそういう難しいコードをチェックしてくれるもの。私の場合はデフォルトよりも少し厳しくして、循環複雑度8以上だったらエラーにするようにした。詳細は以下を参照のこと。
あとデバッグ用に大量に入れていた console.log とか、試行錯誤してるときにコメントアウトして残しておいたコードブロックとか、そのあたりもきれいにしておく。各関数やクラスの説明なども入れておく。
6~7. リポジトリにアップロードする~周辺のものを作る
言わずもがなかもしれないけど、この後段にあるホームページの作成や、サポートページの作成を考えると、GitHub とか GitLab とか BitBucket とかのリポジトリサービスを使っておいたほうがいい。ホームページはリポジトリの Wiki で代用できるし、サポートページはリポジトリの Issue Tracker で代用できる。コードリポジトリだけを非表示にするということもできる。ただし AMO に登録する場合にはコードを難読化するとレビュープロセスが長期化する可能性があるので、あまりコードを秘匿する意味はないのかもしれないけど。
で、周辺のいろいろなもの、ドキュメントとかを作り込む。このあたりは個人的にしんどいところだった。もしチームでやってるのだったら他の人に任せることができるかもしれないけど、開発者本人が書いたほうが間違いがないので、微妙なところ。
AMO申請用の各種素材の作り方は以下をみるとわかる。
ライセンスの選択は重要なところかもしれない。AMO に登録するとき mozilla.org 側で想定しているのは、MPL2.0、GPL2 or 3、GNU Library GPL v2.1 or 3、MIT、BSD、あといわゆる ”All Rights Reserved” で、それ以外は申請できなくはないがどうなるかは知らない、という感じ。AMO に頼らず独自配布するという手段もあるが、マーケットプレイスから気軽にインストールできるメリットを享受しようとすると、秘匿化はある程度妥協しなければいけないかもしれない。
私の場合最初このルールを知らずにコード自体は Apache License 2.0 にし、拡張機能自体を MPL2.0 として申請した。今のところレビューでは何も言われていない。
8. パッケージ化してバリデータのチェックを受ける
バリデータというのはこれのことで、実際に AMO の審査を受ける前に、コードに問題はないかなどをチェックしてくれる。これは必ずやったほうがいい。エラーが出たら当然修正しなければいけないし、後段のレビュープロセスをスムーズに通すためにも Warning レベルの指摘もこの段階で完全に修正しておいたほうがいい。
9~10. AMOに申請〜公開
いよいよ AMO に申請する。私の場合は申請後4時間程度でレビュアーから問題なしとの連絡があり、公開できるようになった。Google や Apple の申請は日単位、週単位という話も聞くので、早いほう(というか爆速)なんじゃないかと思う。
4. おわり
以上です。参考になればうれしいです。