概要 表題の通り、Node.jsで作成したAPIをHerokuにデプロイする工程をまとめました。 CLIが苦手なので、なるべく使わない方向でデプロイします。 環境 Windows10 VSCode グローバル環境に以下をインストールしているものとします。 Node.js（npm） TypeScript API を作成する Node.js、Express、TypeScriptを使用して、APIを作成します。 Herokuにデプロイすることが目的なので、単純なAPIです。 パッケージ インストール 任意のプロジェクトフォルダを作成します。 VSCodeでプロジェクトフォルダを開いて、ターミナルから必要なパッケージをインストールします。 まず、package.jsonを作成します。 ターミナル npm init -y scriptsの項目を以下のように変更します。 package.json "scripts": { "dev": "nodemon dist/main.js" } パッケージをインストールします。 ターミナル npm i express npm i -D @types/node @types/express nodemon nodemon：jsファイルの変更に応じて、サーバーを再起動してくれるパッケージ tsconfig.json ターミナルで以下を実行し、tsconfig.jsonが作成します。 ターミナル tsc --init tsconfig.json { "compilerOptions": { /* Basic Options */ "target": "ES2018", "module": "commonjs", "sourceMap": true, "outDir": "./dist", "rootDir": "./src", /* Strict Type-Checking Options */ "strict": true, /* Module Resolution Options */ "moduleResolution": "Node", "esModuleInterop": true, /* Experimental Options */ "experimentalDecorators": true, /* Advanced Options */ "skipLibCheck": true, "forceConsistentCasingInFileNames": true } } tsファイルをsrcフォルダに、コンパイル後のjsファイルをdistフォルダに格納する設定にしています。 コーディング src/main.ts import express from 'express'; const app = express() // jsonデータを扱う app.use(express.json()) app.use(express.urlencoded({ extended: true })) // テスト用のエンドポイント app.get('/', (req, res) => { res.status(200).send({ message: 'hello, api sever!' }) }) // サーバー接続 const port = process.env.PORT || 3001 app.listen(port, () => { console.log('listen on port:', port) }) 今回は使いませんが、jsonデータを受け取れるように設定しています。 ポートは、ローカル環境では3001（3000はクライアントアプリで使うので）、本番環境ではデプロイ先に依存するように設定します。 起動確認 TypeScriptを使う場合、サーバーを起動する前にJavaScriptファイルにコンパイルする必要があります。 ターミナルで以下を実行します。 ターミナル1 tsc -w -w：tsファイルの変更を監視して、変更があれば自動的にjsファイルに変換する 停止する場合は、Ctrl + C ターミナルをもう一つ追加して、以下を実行します。 ターミナル2 npm run dev このようにすることで、 tsファイルを変更する → jsファイルが生成される（変更される） → サーバーが再起動する という環境ができます。 postmanやブラウザでローカルホストにアクセスして、メッセージが返ってくればOKです。 http://localhost:3001 { "message": "hello, api sever!" } Heroku にデプロイする 設定ファイルの追加・変更 Herokuにデプロイするための設定を追加します。 package.json package.json { "name": "heroku-node-demo", "version": "1.0.0", "description": "", "main": "dist/main.js", "engines": { "node": "14.17.x", "npm": "7.6.3" }, "scripts": { "start": "node dist/main.js", "dev": "nodemon dist/main.js" }, "author": "", "license": "ISC", "dependencies": { "express": "^4.17.1" }, "devDependencies": { "@types/express": "^4.17.13", "@types/node": "^16.4.10", "nodemon": "^2.0.12" } } main、engines、scriptsの項目を変更・追加します。 enginesで、追記するnode、npmバージョンは、以下のコマンドで確認します。 ターミナル node -v > v14.17.1 npm -v > 7.6.3 nodeのバージョンは、パッチバージョンをそのまま追記するとHerokuのデプロイがうまくいかないことがあります。 その場合は、14.17.xのように記述します。 Procfile Herokuのエントリーポイント設定ファイル Procfile web: npm start npm startなので、node dist/main.jsが実行されます。 GitHub HerokuプロジェクトをGitHubリポジトリと関連付けるために、作成したプロジェクトをGitHubに登録します。 GitHubへの登録方法は、まとめている方が多いので割愛します。以下などを参照にしてください。 Herokuへのデプロイ Heroku のアカウントを作成して、ダッシュボードを開きます。 Crete new app でプロジェクトを作成します。 App name を選択して、Create app を押します。 App nameは、ユニークな名前である必要あります。 regionは、アメリカかヨーロッパのどちらかなので、アメリカにします。 デプロイ方法で GitHub を選択し、作成したリポジトリを検索・選択します。 Deploy Branch を押すと、デプロイが始まります。 [Enable Automatic Deploys]を押すと、GitHubのmainブランチに変更があったタイミングで、自動的にデプロイが行われるようになります。toggleボタンになっているので、好きにオンオフできます。 成果物 Tips デバッグ方法 ローカルサーバーでのデバッグ方法についてまとめいてます。

必要なもの 　Windowsで動かす場合にはBluetooth4.0に対応したアダプタが必要になる。私はAmazonでBluetooth USBアダプタを購入した。 事前にインストールするもの 1. python 　https://www.python.org/ からpythonをインストールする。このときにAdd Python 3.x to PATHを必ずインストールする。 2. Zading 　Zadingを使って汎用USBドライバーをインストールする。https://zadig.akeo.ie/ からインストールする。 手順 1. Zading Toolで汎用USBドライバーの適用をする 　インストールしたzading-2.5.exeを起動する。 　optionsからList All Devicesを選択する。Reinstall Driverをクリックする。 　successfullyと出たら完了。 2. toio.jsを動かす 2-1. toio.jsの公式サンプルをクローンする 　(gitが入っていない場合はzipでダウンロードする) ターミナル git clone https://github.com/toio/toio.js.git 2-2. node-bluetooth-hci-socketをダウンロードする 　toio.jsの中でnode-bluetooth-hci-socketをダウンロードする。 ターミナル cd toio.js git clone https://github.com/noble/node-bluetooth-hci-socket.git npm install bluetooth-hci-socket 2-3. 実行する 　toioCubeの電源を入れて、パソコンのBluetoothをオンにしてサンプルを実行する。 ターミナル yarn install yarn build yarn example:id-reader // マットのidを取得する yarn example:keyboard-control // キーボードでcubeを操作する yarn example:chase // 1つのcubeをもう1つのcubeが追いかける

API Gateway + Lambda(Node.js) + MySQL(sequelize)の構成で、Lambdaの処理時間が2.5秒とだいぶ遅かったです。 その後色々手を加えて当初の32%の0.8秒にまで抑えることができたので対応内容をシェアします。 メモリ量調整 定番です。 当初256MBでした。増やせば増やすほど早くなりそうな感じでしたが、コストとの折り合いを見て1024MBに変更しました。 これで平均2.1秒と0.4秒減。 SSM Parameter Storeへの問い合わせを並列実行 コード内で４回Parameter Storeへ値を取得していたのですが、Promise.allを使って並列で取得するようにしました。 1回の値取得に50ミリ秒程度掛かっていたので、これで平均1.95秒と150ミリ秒減りました。 コードのイメージとしてはこんな感じです。 const [dbHost, dbName, dbUser, dbPass] = await Promise.all( [ retrieveDbSetting('DB_HOST'), retrieveDbSetting('DB_DATABASE'), retrieveDbSetting('DB_USERNAME'), retrieveDbSetting('DB_PASSWORD') ] ); DBコネクションプールのアイドル時間を待たずすぐにレスポンスを返す (ほぼこれのおかげ) Sequelizeの設定でpoolというものがあります。 コネクションプーリングの設定なのですが、自分はこれを設定していました。 この時Lambda関数はreturnで処理を終了させていても、コネクションプーリングの待機時間中はLambda関数が終わらないという事になっていました。 解決策としてはコネクションプーリングを削除するか（試してはいませんが）、イベントループ終了を待たないという下記設定をLambdaに書けば大丈夫です。 context.callbackWaitsForEmptyEventLoop = false; npmのdevDependencyをインストールしないようにする 時間の計測はしていなくて微々たるものだとは思いますが一応…。 普通にnpm installするとdevDependencyもインストールされてしまいます。 これを防ぐにはnpm install --productionとするか、環境変数としてNODE_ENV=productionを定義します。 今回は開発・ステージング・本番環境と同じやり方でパッケージを入れたかったので、後者の環境変数で切り替えました。

LambdaでNodemailerを使う機会があったのでメモを残します Nodemailerとは Node.jsで簡単にメールを送ることができるモジュールです。 公式 https://nodemailer.com/about/ npmのページ https://www.npmjs.com/package/nodemailer やりたいこと S3に置いているPDFファイルを添付したメールを送信する 手順 メールアドレスの認証 必要な権限を付与 ローカルでモジュールを準備 Lambdaのコンソール画面でzipをアップロード 1. メールアドレスの認証 サンドボックス解除前のSESは、差出人や宛先に指定するメールアドレスの認証が必要です。 SES Homeを開く Email Addresses > Verify a New Email Address メールアドレスを入力 「Amazon Web Services – Email Address Verification Request in region Asia Pacific (Tokyo)」というメールが届くのでメール内のリンクを踏む 2. 必要な権限を付与 Lambdaの実行ロールの概要画面を開く インラインポリシーの追加 SESのSendRawEmail、S3のGetObjectのアクセス許可を追加する 3. ローカルでモジュールを準備 適当なディレクトリを作成 mkdir test 初期化 npm init nodemailerインストール npm install nodemailer test/node_modulesが作られていることを確認 test/index.jsを作成(中身はlambdaで動かしたいコード) node_modulesとindex.jsをまとめてzip化 4. Lambdaのコンソール画面でzipをアップロード 関数の画面を開く 「アップロード元」のリストから「.zipファイル」を選択 ローカルで作成したzipファイルを指定してアップロード 今回使ったLambdaのコード index.js const AWS = require('aws-sdk') const nodemailer = require('nodemailer') const transporter = nodemailer.createTransport({ SES: new AWS.SES({ apiVersion: '2010-12-01' }), }) const s3 = new AWS.S3({ apiVersion: '2006-03-01' }) const fs = require('fs').promises exports.handler = async (event) => { //S3に置いているPDFを/tmp配下にコピー const paramsForS3 = { Bucket: 'バケット名', Key: 'ファイル名', } const contents = await s3.getObject(paramsForS3).promise() const path = '/tmp/ファイル名' await fs.writeFile(path, contents.Body) // メール送信 await transporter.sendMail({ from: '差出人のメールアドレス', to: '宛先のメールアドレス', subject: 'メールの件名', text: 'メール本文', attachments: [ { filename: '添付ファイル名', //元のファイル名とは別の名前で添付したい場合はここで設定(非必須項目) path: path, }, ], }) }

ブラウザ拡張のクロスブラウザ対応には結構手間がかかります。 特にブラウザごとの違いにはなかなか悩まされます。 デバッグ方法 の相違 パッケージ作成方法 の相違 審査方法・基準 の相違 対応する過程で手間取ったり足踏みしたりすることも多いわけですが、「開発から公開まで」について良くまとまっている記事も見当たりません。 そこで本記事は、ブラウザ拡張の開発から公開までのコストを削減できるよう、以下の2点を説明していきます。 開発の工程を減らす クロスブラウザ拡張用パッケージによる開発・デバッグ・パッケージ化 申請・公開をスムーズに 各ベンダーの審査の共通点・相違点をまとめ、準備の負担を軽減 いつか役に立てていただければ 対象の読者 これからChrome拡張などを作りたい方 拡張のクロスブラウザ対応をしたい方 ただし Chrome, Firefox, Opera, Edge に限ります 各ベンダーの審査の違いについて知りたい方 必要な知識 ターミナルコマンドが打てる npmなどが実行できる 拡張に必要なJavaScript, CSSなどが書ける 作るもの 今回は簡単な例として「Qiita記事のヘッダーを色分けする拡張」を作ります。 Qiita記事の各ヘッダーがこのように表示されるようにします。 （自分がこの機能を欲しかっただけです） 実際に公開したものはこちらです。 Chrome: Qiita Rainbow Header - Chrome ウェブストア Firefox: Qiita Rainbow Header – ? Firefox (ja) 向け拡張機能を入手 Opera: Qiita Rainbow Header extension - Opera add-ons Edge: Qiita Rainbow Header – Microsoft Edge Addons 目次 大きく3つのセクションにわけて説明していきます。 拡張機能の開発 審査の準備 審査・公開 1. 拡張機能の開発 Node.js が必要となりますので、もし入っていない方は こちら からインストールお願いします。 クロスブラウザ対応のため webextension-toolbox というパッケージを使っていきます。 ブラウザごとの違いなどを気にせずに、簡単に各ブラウザ用のパッケージを出力できる神ツールです。 サンプルコード 記事で使っているコードの最終形はこちらに公開しています。 https://github.com/yamadashy-sandbox/webextension-toolbox-example また、今回は記事用に極力シンプルにしたものを使っていきますが、実際に使用しているコードはこちらになります。 webpack部分のカスタムに加え、TypeScriptやESLintなどにも対応しています。 https://github.com/yamadashy/qiita-rainbow-header 雛形からコード生成 さっそく開発していきます。 1. 必要なパッケージをインストール yo 雛形作成パッケージ generator-web-extension webextension-toolbox の雛形作成パッケージ $ npm install -g yo generator-web-extension 2. 開発用のフォルダを作成、移動 $ mkdir my-web-extension && cd $_ 3. コード生成 $ yo web-extension 以下の選択肢以外はそのままEnterで大丈夫です Would you like to use UI Action? Content ScriptsだけSpaceで選択しEnter Would you like to install promo images for the Chrome Web Store? yをおしてEnter 拡張機能の実装 いくつかのファイルを書き換えていきます。 1. app/scripts/contentscript.js を書き換え 今回はJavaScriptは必要ないので中身を消してください。 ファイルを消しても大丈夫です。 2. app/styles/contentscript.css を書き換え .allWrapper .it-MdContent h1 { color: #c35c5c; border-bottom-color: #c35c5c; } .allWrapper .it-MdContent h2 { color: #bf905d; border-bottom-color: #bf905d; } .allWrapper .it-MdContent h3 { color: #9b9b4c; } .allWrapper .it-MdContent h4 { color: #4a944a; } .allWrapper .it-MdContent h5 { color: #468a8a; } .allWrapper .it-MdContent h6 { color: #6464a5; } 3. app/_locals/en/messages.json の書き換え en フォルダの名前を ja にして、 message.json を書き換えてください。 （json内のコメントは消してください） { // 拡張機能の表示名 "appName": { "message": "Qiita Rainbow Header" }, // URLなどに使う短縮名 "appShortName": { "message": "qiita-rainbow-header" }, // 拡張の説明 "appDescription": { "message": "Qiita記事のヘッダーの色を段階によって変えます" } } 4. app/manifest.json を書き換え { "manifest_version": 2, // messages.json から自動で取得されます "name": "__MSG_appName__", "short_name": "__MSG_appShortName__", "description": "__MSG_appDescription__", // 自由な値で大丈夫です "version": "0.1.0", "default_locale": "ja", "author": "作者名", // 拡張のアイコン "icons": { "16": "images/icon-16.png", "128": "images/icon-128.png" }, "content_scripts": [ { // 拡張を有効化するURLにマッチする文字列 "matches": [ "https://qiita.com/*" ], "js": [ "scripts/contentscript.js" ], "css": [ "styles/contentscript.css" ], // 実行タイミング。document_startはDOMの読み込み中 "run_at": "document_start" } ] } manifest.json についてはここが参考になるかと思います。 また、run_at についてはこちらを参考に。 これで機能の実装は終わりです。 アイコンの変更などは後ほど説明します。 各ブラウザでデバッグ ブラウザ共通 以下のコマンドで開発用にビルドでき、dist/<ブラウザ名> のフォルダに出力されます。 $ npm run dev <ブラウザ名> # 以下のどれか $ npm run dev chrome $ npm run dev firefox $ npm run dev opera $ npm run dev edge また、この開発用ビルドを終了させない限りは、ファイル変更を検知して自動で再ビルドしてくれます。 Chrome拡張のデバッグ URL欄に chrome://extensions でEnter 右上の「デベロッパーモード」をON dist/chrome フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 無事、ヘッダーの色が変わることを確認できました。 Firefoxアドオンのデバッグ URL欄に about:debugging#/runtime/this-firefox でEnter 「一時的なアドオンを読み込む...」から dist/firefox/manifest.json を開く 対象ページを再読み込みして確認 Operaアドオンのデバッグ URL欄に opera://extensions でEnter 右上の「開発者モード」をON dist/opera フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 対応したいブラウザの確認ができたら、審査の準備をしていきます。 Edge拡張のデバッグ URL欄に edge://extensions でEnter 左下の「開発者モード」をON dist/edge フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 2. 審査の準備 アイコン画像などの用意 各ブラウザで用途などを比較していきます。 アイコン画像 最低限 128x128 が必要です。 各ブラウザごとの違いの表です。 サイズ Chrome Firefox Opera Edge 全般 必須サイズありガイドライン なければデフォルト Chromeと同じ Chromeと同じ 16x16 拡張機能ページのファビコン Chromeと同じ Chromeと同じ 32x32 Windows向けにあると良い 48x48 拡張機能ページ 理想のサイズ Chromeと同じ Chromeと同じ 96x96 表示される実際のサイズ 公式の例で使用 128x128 必須。Chromeウェブストア Chromeと同じ Chromeと同じ 画像が用意できたら app/images フォルダに入れ、 app/manifest.json も用意した画像の分書き換えてください。 以下は 48x48 128x128 を用意したパターンです。 - "16": "images/icon-16.png", - "128": "images/icon-128.png" + "48": "images/icon-48.png", + "128": "images/icon-128.png" 今回はFireAlpacaというペイントソフトで適当にアイコンを作りました。 プロモーション画像 440x280 が必要となります。 スクリーンショットだと弾かれる可能性がありますが、用意が面倒なのでスクショで一旦申請してみても良いと思います。 サイズ Chrome Firefox Opera Edge 全般 画像ありは優先表示 設定不可 未設定だとフィーチャーされない 440x280 必須。Small x x 必須 920x680 Large x x 1400x560 Marquee x x あると良い 300x188 x 設定可能 スクリーンショット画像 1つは必要です。 1280x800 があると良いと思います。 サイズ Chrome Firefox Opera Edge 全般 最低1つ あると良い(?) ないとリジェクトの可能性あり あると良い 640x400 設定可 設定可 1280x800 望ましい 設定可 詳細用の文章の用意 messages.json のdescriptionとは別に、下の赤枠に表示するような詳細な文章が表示できます。 こちらは効率化のためなので任意ですが、コードで管理しておいたほうが多言語化の際に楽になります。 自分の場合は、 app/_locals/<言語コード>/detailed-description.txt に入れています。 プライバシーポリシー アナリティクスなど、個人情報を収集する処理を入れている場合は必要となります。 今回の記事は特にデータ収集などはしていないですが、以下のようなプラポリを設定しています。 https://github.com/yamadashy/qiita-rainbow-header/wiki/Privacy-Policy-JA レビュアー用の説明 レビュアーが拡張機能を試す際に必要な情報を事前にまとめておきます。Firefox, Edgeの申請時に使います。 確認用のURL 確認の手順 SNS用の拡張など、アカウントが必要となる場合はデバッグ用アカウントの情報 この拡張だと以下のようになります。 確認手順 1. 拡張機能をインストール 2. qiita.com を開き、適当な記事に飛びます 3. 記事内のヘッダーの色が変わっていることが確認できます。 Slackの拡張を作るとしたらこんな感じになると思います。 確認用の情報 - Slackワークスペース: 〇〇〇.slack.com - アカウント: 〇〇〇@gmail.com - パスワード: 〇〇〇 確認手順 1. 拡張機能をインストール 2. slackのワークスペースにログイン 3. 〇〇〇が確認できます パッケージ化 審査に提出するためのパッケージを作ります。 以下のコマンドで各ブラウザ向けのパッケージが packages フォルダに出力されます $ npm run build <ブラウザ名> # 以下のどれか $ npm run build chrome $ npm run build firefox $ npm run build opera $ npm run build edge レビュー提出用ソースコード Firefoxのレビューでは必要になります。 git管理している場合は git archive で簡単にzipが作れます。 $ git archive HEAD -o source.zip package.json の scripts に追加しておくと便利です { "scripts": { "archive": "git archive HEAD -o source.zip" } } 3. 審査・公開 いよいよ申請です。 各ベンダーへの審査について、迷いそうな点を重点的に説明していきます。 ブラウザ共通 以下の情報があると良いです。 Webサイトなどは、GitHubのリポジトリをREADMEを置くだけでも良いので作ると便利です。 拡張の情報 Webサイト ... GitHubのURLで大丈夫です サポートページ ... GitHubのissueページ プライバシーポリシー ... GitHubのWikiにページを作って設定 ストアの情報 説明 ... 事前に説明をまとめておきます。 または detailed-description.txt を使います Chrome拡張の申請 公式のガイドライン 1. 開発者アカウント登録 Googleアカウントを作り、デベロッパーとして登録します。 最初だけ500円の支払いが必要です。 https://chrome.google.com/webstore/devconsole/register 2. パッケージのアップロード 以下のページを開き「新しいアイテム」からアップロードできます。 https://chrome.google.com/webstore/devconsole/ 3. 内容を設定 「ストア掲載情報」を設定 説明 ... 事前にまとめた内容か detailed-description.txt を使います カテゴリ選択 画像設定 ... 用意しておいたアイコンとスクショなどを設定 ホームページURL ... GitHubのページなど サポートURL ... GitHubのissueページなど 「プライバシーへの取り組み」を設定 拡張機能の用途 権限が必要な理由 ... なにかしらの権限を要求している場合は、権限ごとにその理由を記載 データ使用 ... 特にデータを使用していない場合は、下のほうにある3つのチェックボックスを選択しておけば大丈夫です 最近のChromeは審査が厳しくなっているので、使用する権限は必要最低限にしたほうが良いです。 4. プライバシーポリシーの設定 ダッシュボードのトップページの「アカウント」から設定します。 プライバシーポリシーを設定しないとリジェクトされる可能性があります。 今回は以下のように記載しています。 ユーザーのデータを収集するか、収集する場合どう扱うかなどを明記していれば大丈夫なようです。 https://github.com/yamadashy/qiita-rainbow-header/wiki/Privacy-Policy-JA 5. 審査待ち https://chrome.google.com/webstore/devconsole 1,2日で審査結果が出ます。 体感的にリジェクトされるときは3,4日経ってからリジェクトされます。 Firefoxアドオンの申請 1. 開発者アカウント登録 開発者アカウント登録します。 https://addons.mozilla.org/ja/developers/ 2. パッケージのアップロード 「新しいアドオンを登録」ページを開き、パッケージをアップロードします。 https://addons.mozilla.org/ja/developers/addon/submit/distribution また、今回のようにwebpackなどを使用している場合は、ソースコードの提出が必要なので、レビュー提出用ソースコード の項を参考にzipを作り提出します。 3. 内容を設定 以下を埋めていきます 概要 ... 特に変更は必要ないです。 説明 ... 用意した内容か detailed-description.txt を使います カテゴリ選択 メールアドレス サポートサイト ... GitHubのissueページなど ライセンス 審査担当者へのメモ ... 拡張機能の説明や動作確認の手順などを書きます 一旦ここで登録が完了し審査が始まりますが、まだアイコンなどを登録していないので編集します。 4. アイコンなどの設定 アドオン管理ページから対象のアドオンのページを開きます。 https://addons.mozilla.org/ja/developers/addons 画像の「編集」ボタンから、アイコンとスクショを設定できます。 5. 審査待ち https://addons.mozilla.org/ja/developers/addons 2,3日で審査結果が出ます。 以前はかなり早かったのですが、コロナによる影響で遅くなっているようです。 Operaアドオンの申請 公式のガイドライン 1. Operaアカウントを作成 以下からOperaのアカウントを作成します。 https://auth.opera.com/account/signup 2. パッケージをアップロード Opera拡張ダッシュボードを開き「Upload new addon」からアップロードします。 https://addons.opera.com/developer/ 3. 内容を設定 「General」の設定 カテゴリ 「I want my extension to be available for auto-publishing.」にチェック。自動で公開するかの設定です。 「Versions」の設定 気づきづらいのですが、Versionsタブ内に表示されている各バージョンをクリックして、パッケージ説明などの編集ができます。 以下の項目を設定します。 1つ設定するごとにチェックマークで保存するのを忘れないようにしてください。 General ウェブサイトURL サポートURL ,,, GitHubのissueページなど ソースコードURL ... GitHubのページで大丈夫です（ソースが公開されている場合） 審査担当者用の情報 ソースコードURL ビルド方法 ... 審査担当者用にコードのビルド方法を記載 ライセンス プライバシーポリシー ... URLだけで良いです。 Media スクショ 1280x800 アイコン 64x64 Translations 用意した内容か detailed-description.txt を使います 記入が終わったらGeneralの「Submit Changes」で保存します。 同時に審査も始まります。 「Promotional Image」の設定 300x188 の画像を設定します 4. 審査待ち 「Conversation」タブで確認できます。 自分の場合は3分で審査が通りました。 よっぽど内容がおかしくない場合は一瞬で通りそうです。 Edge拡張の申請 公式のガイドライン 1. アカウント作成 Microsoftのアカウントを作成し、開発者として登録してください。 https://partner.microsoft.com/dashboard/microsoftedge 2. パッケージのアップロード 以下のページの「拡張機能を作成」からパッケージをアップロードします。 https://partner.microsoft.com/ja-jp/dashboard/microsoftedge/overview 3. 内容を設定 以下のようなページになるので、左側の「プロパティ」などを選択して設定していきます。 「プロパティの設定」を設定 カテゴリ プライバシーポリシー Webサイト サポート連絡先（サポートサイト） ... GitHubのissueページなど 「Store登録情報」を設定 画像のドラッグ&ドロップなどもできず、また多言語対応している場合は1つ1つ設定しないといけないので結構面倒です。 拡張機能の説明 ... message.json と detailed-description.txt をあわせた内容を設定します。 4. 審査用の説明を記載 最後に審査担当者が確認するための説明を記載して申請します。 5. 審査待ち https://partner.microsoft.com/ja-jp/dashboard/microsoftedge/overview 審査結果が出るまで4,5日程度かかります。 7営業日以内には審査結果が出ると公式には書かれています。 公開 無事すべて公開されました。 Chrome: Qiita Rainbow Header - Chrome ウェブストア Firefox: Qiita Rainbow Header – ? Firefox (ja) 向け拡張機能を入手 Opera: Qiita Rainbow Header extension - Opera add-ons Edge: Qiita Rainbow Header – Microsoft Edge Addons 審査は体感だとOperaが一番早くEdgeが一番遅いです。 またChromeが一番厳しいです。 おわりに 要点だけを書きましたが、それでもやること多いですね。 各ベンダーで協力して共通の拡張ストアページ作ってくれないですかね...。 最近のニュースで 大手のベンダー達がブラウザ拡張を改善するワーキンググループを作った みたいな話があるので、改善されていくことを願います。

ブラウザ拡張のクロスブラウザ対応には結構手間がかかります。 特にブラウザごとの違いにはなかなか悩まされます。 デバッグ方法 の相違 パッケージ作成方法 の相違 審査方法・基準 の相違 対応する過程で手間取ったり足踏みしたりすることも多いわけですが、「開発から公開まで」について良くまとまっている記事も見当たりません。 そこで本記事は、ブラウザ拡張の開発から公開までのコストを削減できるよう、以下の2点を説明していきます。 開発の工程を減らす クロスブラウザ拡張用パッケージによる開発・デバッグ・パッケージ化 申請・公開をスムーズに 各ベンダーの審査の共通点・相違点をまとめ、準備の負担を軽減 いつか役に立てていただければ 対象の読者 これからChrome拡張などを作りたい方 拡張のクロスブラウザ対応をしたい方 ただし Chrome, Firefox, Opera, Edge に限ります 各ベンダーの審査の違いについて知りたい方 必要な知識 ターミナルコマンドが打てる npmなどが実行できる 拡張に必要なJavaScript, CSSなどが書ける 作るもの 今回は簡単な例として「Qiita記事のヘッダーを色分けする拡張」を作ります。 Qiita記事の各ヘッダーがこのように表示されるようにします。 （自分がこの機能を欲しかっただけです） 実際に公開したものはこちらです。 Chrome: Qiita Rainbow Header - Chrome ウェブストア Firefox: Qiita Rainbow Header – ? Firefox (ja) 向け拡張機能を入手 Opera: Qiita Rainbow Header extension - Opera add-ons Edge: Qiita Rainbow Header – Microsoft Edge Addons 目次 大きく3つのセクションにわけて説明していきます。 拡張機能の開発 審査の準備 審査・公開 1. 拡張機能の開発 Node.js が必要となりますので、もし入っていない方は こちら からインストールお願いします。 クロスブラウザ対応のため webextension-toolbox というパッケージを使っていきます。 ブラウザごとの違いなどを気にせずに、簡単に各ブラウザ用のパッケージを出力できる神ツールです。 サンプルコード 記事で使っているコードの最終形はこちらに公開しています。 https://github.com/yamadashy-sandbox/webextension-toolbox-example また、今回は記事用に極力シンプルにしたものを使っていきますが、実際に使用しているコードはこちらになります。 webpack部分のカスタムに加え、TypeScriptやESLintなどにも対応しています。 https://github.com/yamadashy/qiita-rainbow-header 雛形からコード生成 さっそく開発していきます。 1. 必要なパッケージをインストール yo 雛形作成パッケージ generator-web-extension webextension-toolbox の雛形作成パッケージ $ npm install -g yo generator-web-extension 2. 開発用のフォルダを作成、移動 $ mkdir my-web-extension && cd $_ 3. コード生成 $ yo web-extension 以下の選択肢以外はそのままEnterで大丈夫です Would you like to use UI Action? Content ScriptsだけSpaceで選択しEnter Would you like to install promo images for the Chrome Web Store? yをおしてEnter 拡張機能の実装 いくつかのファイルを書き換えていきます。 1. app/scripts/contentscript.js を書き換え 今回はJavaScriptは必要ないので中身を消してください。 ファイルを消しても大丈夫です。 2. app/styles/contentscript.css を書き換え .allWrapper .it-MdContent h1 { color: #c35c5c; border-bottom-color: #c35c5c; } .allWrapper .it-MdContent h2 { color: #bf905d; border-bottom-color: #bf905d; } .allWrapper .it-MdContent h3 { color: #9b9b4c; } .allWrapper .it-MdContent h4 { color: #4a944a; } .allWrapper .it-MdContent h5 { color: #468a8a; } .allWrapper .it-MdContent h6 { color: #6464a5; } 3. app/_locals/en/messages.json の書き換え en フォルダの名前を ja にして、 message.json を書き換えてください。 （json内のコメントは消してください） { // 拡張機能の表示名 "appName": { "message": "Qiita Rainbow Header" }, // URLなどに使う短縮名 "appShortName": { "message": "qiita-rainbow-header" }, // 拡張の説明 "appDescription": { "message": "Qiita記事のヘッダーの色を段階によって変えます" } } 4. app/manifest.json を書き換え { "manifest_version": 2, // messages.json から自動で取得されます "name": "__MSG_appName__", "short_name": "__MSG_appShortName__", "description": "__MSG_appDescription__", // 自由な値で大丈夫です "version": "0.1.0", "default_locale": "ja", "author": "作者名", // 拡張のアイコン "icons": { "16": "images/icon-16.png", "128": "images/icon-128.png" }, "content_scripts": [ { // 拡張を有効化するURLにマッチする文字列 "matches": [ "https://qiita.com/*" ], "js": [ "scripts/contentscript.js" ], "css": [ "styles/contentscript.css" ], // 実行タイミング。document_startはDOMの読み込み中 "run_at": "document_start" } ] } manifest.json についてはここが参考になるかと思います。 また、run_at についてはこちらを参考に。 これで機能の実装は終わりです。 アイコンの変更などは後ほど説明します。 各ブラウザでデバッグ ブラウザ共通 以下のコマンドで開発用にビルドでき、dist/<ブラウザ名> のフォルダに出力されます。 $ npm run dev <ブラウザ名> # 以下のどれか $ npm run dev chrome $ npm run dev firefox $ npm run dev opera $ npm run dev edge また、この開発用ビルドを終了させない限りは、ファイル変更を検知して自動で再ビルドしてくれます。 Chrome拡張のデバッグ URL欄に chrome://extensions でEnter 右上の「デベロッパーモード」をON dist/chrome フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 無事、ヘッダーの色が変わることを確認できました。 Firefoxアドオンのデバッグ URL欄に about:debugging#/runtime/this-firefox でEnter 「一時的なアドオンを読み込む...」から dist/firefox/manifest.json を開く 対象ページを再読み込みして確認 Operaアドオンのデバッグ URL欄に opera://extensions でEnter 右上の「開発者モード」をON dist/opera フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 対応したいブラウザの確認ができたら、審査の準備をしていきます。 Edge拡張のデバッグ URL欄に edge://extensions でEnter 左下の「開発者モード」をON dist/edge フォルダをドラッグ&ドロップ 対象ページを再読み込みして確認 2. 審査の準備 アイコン画像などの用意 各ブラウザで用途などを比較していきます。 アイコン画像 最低限 128x128 が必要です。 各ブラウザごとの違いの表です。 サイズ Chrome Firefox Opera Edge 全般 必須サイズありガイドライン なければデフォルト Chromeと同じ Chromeと同じ 16x16 拡張機能ページのファビコン Chromeと同じ Chromeと同じ 32x32 Windows向けにあると良い 48x48 拡張機能ページ 理想のサイズ Chromeと同じ Chromeと同じ 96x96 表示される実際のサイズ 公式の例で使用 128x128 必須。Chromeウェブストア Chromeと同じ Chromeと同じ 画像が用意できたら app/images フォルダに入れ、 app/manifest.json も用意した画像の分書き換えてください。 以下は 48x48 128x128 を用意したパターンです。 - "16": "images/icon-16.png", - "128": "images/icon-128.png" + "48": "images/icon-48.png", + "128": "images/icon-128.png" 今回はFireAlpacaというペイントソフトで適当にアイコンを作りました。 プロモーション画像 440x280 が必要となります。 スクリーンショットだと弾かれる可能性がありますが、用意が面倒なのでスクショで一旦申請してみても良いと思います。 サイズ Chrome Firefox Opera Edge 全般 画像ありは優先表示 設定不可 未設定だとフィーチャーされない 440x280 必須。Small x x 必須 920x680 Large x x 1400x560 Marquee x x あると良い 300x188 x 設定可能 スクリーンショット画像 1つは必要です。 1280x800 があると良いと思います。 サイズ Chrome Firefox Opera Edge 全般 最低1つ あると良い(?) ないとリジェクトの可能性あり あると良い 640x400 設定可 設定可 1280x800 望ましい 設定可 詳細用の文章の用意 messages.json のdescriptionとは別に、下の赤枠に表示するような詳細な文章が表示できます。 こちらは効率化のためなので任意ですが、コードで管理しておいたほうが多言語化の際に楽になります。 自分の場合は、 app/_locals/<言語コード>/detailed-description.txt に入れています。 プライバシーポリシー アナリティクスなど、個人情報を収集する処理を入れている場合は必要となります。 今回の記事は特にデータ収集などはしていないですが、以下のようなプラポリを設定しています。 https://github.com/yamadashy/qiita-rainbow-header/wiki/Privacy-Policy-JA レビュアー用の説明 レビュアーが拡張機能を試す際に必要な情報を事前にまとめておきます。Firefox, Edgeの申請時に使います。 確認用のURL 確認の手順 SNS用の拡張など、アカウントが必要となる場合はデバッグ用アカウントの情報 この拡張だと以下のようになります。 確認手順 1. 拡張機能をインストール 2. qiita.com を開き、適当な記事に飛びます 3. 記事内のヘッダーの色が変わっていることが確認できます。 Slackの拡張を作るとしたらこんな感じになると思います。 確認用の情報 - Slackワークスペース: 〇〇〇.slack.com - アカウント: 〇〇〇@gmail.com - パスワード: 〇〇〇 確認手順 1. 拡張機能をインストール 2. slackのワークスペースにログイン 3. 〇〇〇が確認できます パッケージ化 審査に提出するためのパッケージを作ります。 以下のコマンドで各ブラウザ向けのパッケージが packages フォルダに出力されます $ npm run build <ブラウザ名> # 以下のどれか $ npm run build chrome $ npm run build firefox $ npm run build opera $ npm run build edge レビュー提出用ソースコード Firefoxのレビューでは必要になります。 git管理している場合は git archive で簡単にzipが作れます。 $ git archive HEAD -o source.zip package.json の scripts に追加しておくと便利です { "scripts": { "archive": "git archive HEAD -o source.zip" } } 3. 審査・公開 いよいよ申請です。 各ベンダーへの審査について、迷いそうな点を重点的に説明していきます。 ブラウザ共通 以下の情報があると良いです。 Webサイトなどは、GitHubのリポジトリをREADMEを置くだけでも良いので作ると便利です。 拡張の情報 Webサイト ... GitHubのURLで大丈夫です サポートページ ... GitHubのissueページ プライバシーポリシー ... GitHubのWikiにページを作って設定 ストアの情報 説明 ... 事前に説明をまとめておきます。 または detailed-description.txt を使います Chrome拡張の申請 公式のガイドライン 1. 開発者アカウント登録 Googleアカウントを作り、デベロッパーとして登録します。 最初だけ500円の支払いが必要です。 https://chrome.google.com/webstore/devconsole/register 2. パッケージのアップロード 以下のページを開き「新しいアイテム」からアップロードできます。 https://chrome.google.com/webstore/devconsole/ 3. 内容を設定 「ストア掲載情報」を設定 説明 ... 事前にまとめた内容か detailed-description.txt を使います カテゴリ選択 画像設定 ... 用意しておいたアイコンとスクショなどを設定 ホームページURL ... GitHubのページなど サポートURL ... GitHubのissueページなど 「プライバシーへの取り組み」を設定 拡張機能の用途 権限が必要な理由 ... なにかしらの権限を要求している場合は、権限ごとにその理由を記載 データ使用 ... 特にデータを使用していない場合は、下のほうにある3つのチェックボックスを選択しておけば大丈夫です 最近のChromeは審査が厳しくなっているので、使用する権限は必要最低限にしたほうが良いです。 4. プライバシーポリシーの設定 ダッシュボードのトップページの「アカウント」から設定します。 プライバシーポリシーを設定しないとリジェクトされる可能性があります。 今回は以下のように記載しています。 ユーザーのデータを収集するか、収集する場合どう扱うかなどを明記していれば大丈夫なようです。 https://github.com/yamadashy/qiita-rainbow-header/wiki/Privacy-Policy-JA 5. 審査待ち https://chrome.google.com/webstore/devconsole 1,2日で審査結果が出ます。 体感的にリジェクトされるときは3,4日経ってからリジェクトされます。 Firefoxアドオンの申請 1. 開発者アカウント登録 開発者アカウント登録します。 https://addons.mozilla.org/ja/developers/ 2. パッケージのアップロード 「新しいアドオンを登録」ページを開き、パッケージをアップロードします。 https://addons.mozilla.org/ja/developers/addon/submit/distribution また、今回のようにwebpackなどを使用している場合は、ソースコードの提出が必要なので、レビュー提出用ソースコード の項を参考にzipを作り提出します。 3. 内容を設定 以下を埋めていきます 概要 ... 特に変更は必要ないです。 説明 ... 用意した内容か detailed-description.txt を使います カテゴリ選択 メールアドレス サポートサイト ... GitHubのissueページなど ライセンス 審査担当者へのメモ ... 拡張機能の説明や動作確認の手順などを書きます 一旦ここで登録が完了し審査が始まりますが、まだアイコンなどを登録していないので編集します。 4. アイコンなどの設定 アドオン管理ページから対象のアドオンのページを開きます。 https://addons.mozilla.org/ja/developers/addons 画像の「編集」ボタンから、アイコンとスクショを設定できます。 5. 審査待ち https://addons.mozilla.org/ja/developers/addons 2,3日で審査結果が出ます。 以前はかなり早かったのですが、コロナによる影響で遅くなっているようです。 Operaアドオンの申請 公式のガイドライン 1. Operaアカウントを作成 以下からOperaのアカウントを作成します。 https://auth.opera.com/account/signup 2. パッケージをアップロード Opera拡張ダッシュボードを開き「Upload new addon」からアップロードします。 https://addons.opera.com/developer/ 3. 内容を設定 「General」の設定 カテゴリ 「I want my extension to be available for auto-publishing.」にチェック。自動で公開するかの設定です。 「Versions」の設定 気づきづらいのですが、Versionsタブ内に表示されている各バージョンをクリックして、パッケージ説明などの編集ができます。 以下の項目を設定します。 1つ設定するごとにチェックマークで保存するのを忘れないようにしてください。 General ウェブサイトURL サポートURL ,,, GitHubのissueページなど ソースコードURL ... GitHubのページで大丈夫です（ソースが公開されている場合） 審査担当者用の情報 ソースコードURL ビルド方法 ... 審査担当者用にコードのビルド方法を記載 ライセンス プライバシーポリシー ... URLだけで良いです。 Media スクショ 1280x800 アイコン 64x64 Translations 用意した内容か detailed-description.txt を使います 記入が終わったらGeneralの「Submit Changes」で保存します。 同時に審査も始まります。 「Promotional Image」の設定 300x188 の画像を設定します 4. 審査待ち 「Conversation」タブで確認できます。 自分の場合は3分で審査が通りました。 よっぽど内容がおかしくない場合は一瞬で通りそうです。 Edge拡張の申請 公式のガイドライン 1. アカウント作成 Microsoftのアカウントを作成し、開発者として登録してください。 https://partner.microsoft.com/dashboard/microsoftedge 2. パッケージのアップロード 以下のページの「拡張機能を作成」からパッケージをアップロードします。 https://partner.microsoft.com/ja-jp/dashboard/microsoftedge/overview 3. 内容を設定 以下のようなページになるので、左側の「プロパティ」などを選択して設定していきます。 「プロパティの設定」を設定 カテゴリ プライバシーポリシー Webサイト サポート連絡先（サポートサイト） ... GitHubのissueページなど 「Store登録情報」を設定 画像のドラッグ&ドロップなどもできず、また多言語対応している場合は1つ1つ設定しないといけないので結構面倒です。 拡張機能の説明 ... message.json と detailed-description.txt をあわせた内容を設定します。 4. 審査用の説明を記載 最後に審査担当者が確認するための説明を記載して申請します。 5. 審査待ち https://partner.microsoft.com/ja-jp/dashboard/microsoftedge/overview 審査結果が出るまで4,5日程度かかります。 7営業日以内には審査結果が出ると公式には書かれています。 公開 無事すべて公開されました。 Chrome: Qiita Rainbow Header - Chrome ウェブストア Firefox: Qiita Rainbow Header – ? Firefox (ja) 向け拡張機能を入手 Opera: Qiita Rainbow Header extension - Opera add-ons Edge: Qiita Rainbow Header – Microsoft Edge Addons 審査は体感だとOperaが一番早くEdgeが一番遅いです。 またChromeが一番厳しいです。 おわりに 要点だけを書きましたが、それでもやること多いですね。 各ベンダーで協力して共通の拡張ストアページ作ってくれないですかね...。 最近のニュースで 大手のベンダー達がブラウザ拡張を改善するワーキンググループを作った みたいな話があるので、改善されていくことを願います。