例えば wasavi の起動時、終了時、あるいは何かエラーが発生したときなど、コード中の何箇所かで console.(log|error|info) している。これはデバッグの際にちょっと役に立つ。

さて実は、Firefox 版 wasavi の full review をしてもらった際、「次に更新するときはログは取っといてね。製品バージョンでふつうこんなことしねーから」と申し渡されている。そうか？　と疑問に思わなくもないがちょっと考えてみることにしよう。

前述の通りログはデバッグに役立つ。自分でコードを書いて自分で動作を確認するときはもちろん、製品版であっても「～が動かない」「～のログは出てる？」というやり取りがよくあるのであって困るものではない。しかしまあこれは譲歩しよう。開発時はログを出し、公開版では出さないようにする。これで文句はあるまい。

これはまるでネイティブアプリの Debug ビルドと Release ビルドみたいな話だが、もちろんブラウザのエクステンションにはそういう区別は特にない。実行時に自分が開発バージョンか否かを判断できるような何か代替になるものを作らなければならない。

現在 wasavi のバージョンは 0.4 である。これが例えば 0.0 に戻ることはありえない。そこで、0.0 = 開発版ということにしよう。manifest.json、config.xml、package.json のそれぞれのバージョン情報を 0.0.1 にし、バックグラウンドの起動時に保持しておく。また wasavi が起動した際は開発版かどうかを通知し、開発版のときのみ console.なんちゃらを実行するようにする。

ということでそうした。

ところでエクステンションが自身のバージョン情報を得る方法として、Opera は widget.version、Firefox は require(‘self’).version を単に参照するだけでいいのに対して、Chrome の場合は manifest.json に management パーミッションを追加した上で chrome.management.version を参照しないといけない。

Chrome エクステンションでパーミッションの拡大は割と一大イベントである。エクステンションが更新されたとき、「なんかこのエクステンションがさらなるパーミッション要求してるけど、どうする？」とか聞かれたと思う。こんなダイアログ出たらだいたいの人は怖がって漏らしてしまう。もちろん本当に重要な機能追加のためにパーミッション拡大が必要になったら、そのときはせざるを得ないが、ドキュメントに大書するなり web サイトでアナウンスするなりといったフォローもあわせて行う必要があると思う。

翻ってバージョン情報の参照だが、これはぜんぜん重要な機能追加でもなんでもない。どうしたものか。

　＊　＊　＊

management API を使わず、直接 manifest.json を xhr で読んで version を参照するようにした。