electronのボイラープレートの中でもシェアが高く使い勝手の良いelectron-react-boilerplate
https://github.com/electron-react-boilerplate/electron-react-boilerplate
typescriptビルド環境からreact/redux react-routerなどのライブラリ群も入っていて尚且つテストツールやpre-commitまで入って至れり尽くせり。
そのまま使えばリッチな環境で開発が行えるが故に、定義ファイル群を理解せずに使いがち
あれこれディレクトリ構成を変えてるうちに動かなくなった なんてことにならないように一つ一つ読んで理解していこうと思う。
この記事ではpackage.jsonに書かれている定義から読み解いていく。
この記事で書かないこと
「electron-react-boilerplateの」package.jsonの機能的な部分だけに触れていくので以下のようなpackage.json自身のフィールドには触れない
repository, author contributors, license, bugs, keywords, homepage ...etc
electron-builderだとか、pre-commitなど拡張されたフィールドについて見ていく。
package.jsonに書かれているフィールド
package.jsonの定義を一つ一つ見ていく
lint-stagedフィールド
"lint-staged":{"*.{js,jsx,ts,tsx}":["cross-env NODE_ENV=development eslint --cache"],"{*.json,.{babelrc,eslintrc,prettierrc,stylelintrc}}":["prettier --ignore-path .eslintignore --parser json --write"],"*.{css,scss}":["stylelint --ignore-path .eslintignore --syntax scss --fix","prettier --ignore-path .eslintignore --single-quote --write"],"*.{html,md,yml}":["prettier --ignore-path .eslintignore --single-quote --write"]}stageされたファイルを対象にlintをかけるlint-stagedに関する定義が書かれるフィールド
Readmeを参考に読み解いていく
https://github.com/okonet/lint-staged
1つ目
"*.{js,jsx,ts,tsx}":["cross-env NODE_ENV=development eslint --cache"],gitにstageされたjs, jsx, ts, tsxファイルに対してeslintを実行する
2つ目
"{*.json,.{babelrc,eslintrc,prettierrc,stylelintrc}}":["prettier --ignore-path .eslintignore --parser json --write"],.eslintignoreに記載されているものを除き、jsonと各rcファイルに対してprettierを実行する
3つ目
"*.{css,scss}":["stylelint --ignore-path .eslintignore --syntax scss --fix","prettier --ignore-path .eslintignore --single-quote --write"],.eslintignoreに記載されているものを除き、 css, scssファイルに対してstylelintとprettierを実行してファイルを修正する
4つ目
"*.{html,md,yml}":["prettier --ignore-path .eslintignore --single-quote --write"].eslintignoreに記載されているものを除き、 html, md, ymlファイルに対してprettierを実行してファイルを修正する
buildフィールド
"build":{"productName":"ElectronReact","appId":"org.develar.ElectronReact","files":["dist/","node_modules/","app.html","main.prod.js","main.prod.js.map","package.json"],"dmg":{"contents":[{"x":130,"y":220},{"x":410,"y":220,"type":"link","path":"/Applications"}]},electron-react-boilerplateが内包しているビルドモジュール electron-builderの定義が書かれているフィールド
公式ドキュメントを見ながら読み解いていく
https://www.electron.build/configuration/configuration
productName
アプリの名前 パッケージ化した時のファイル名になる。
スペースや特殊文字は使用不可とのこと
appId
MacではCFBundleIdentifier、WindowsではApplication User Model IDsとして使われる文字列
アプリケーションを識別するのに使う
files
packageのなかに含めるリソースファイルを定義する
ビルドファイルやnode_modulesなどが含まれる
directories
buildResources -> ビルド時に使用するリソースディレクトリ名 この中に入れたファイルがアプリに含まれると言うわけではなく、含めたいファイルはfilesフィールドで定義する必要があるらしい。
output -> パッケージ時の出力ディレクトリ名
dmg
Macのdmgファイルをどのように作成するかの定義
contents -> iconの表示位置などの設定 x,yはアイコンの中心位置への参照
win
windows用のビルドの設定項目
target -> ビルドで出力するファイルのタイプ
Linux
Linux用のビルドの設定項目
target -> ビルドで出力するファイルのタイプ
jestフィールド
"jest":{"testURL":"http://localhost/","moduleNameMapper":{"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$":"<rootDir>/internals/mocks/fileMock.js","\\.(css|less|sass|scss)$":"identity-obj-proxy"},"moduleFileExtensions":["js","jsx","ts","tsx","json"],"moduleDirectories":["node_modules","app/node_modules"],"setupFiles":["./internals/scripts/CheckBuildsExist.js"]},テストランナーのjestの定義が書かれるフィールド
公式ドキュメントのConfigガイドを見ながら読み解いていく
https://jestjs.io/docs/ja/configuration
testURL
jsdom環境に与えられるURL defaultはabout:blankになっており、問題を起こすケースがあるのでlocalhostが入っている様子
moduleNameMapper
テストでは扱いづらい画像ファイル、フォントファイルなどのリソースをモックするための記述
画像、音声、動画ファイルなどは fileMock.js の内容でモックされる('test-file-stub'という文字列）
style関連のファイルはidentity-obj-proxyによってmockされる
https://github.com/keyz/identity-obj-proxy
moduleFileExtensions
使用するモジュールの拡張子を羅列する配列
公式ドキュメントによるとプロジェクトの中で一番頻度高く使用する拡張子を配列の最初に持ってくることが推奨されている。
typescriptを使用するならts, tsxを配列の最初に移動した方がテストのパフォーマンスが向上するだろう。
moduleDirectories
モジュールが格納されているディレクトリ名の配列を指定する。defaultはnode_modulesだが、app配下にも存在するので、app/node_modulesを追加した配列を指定している
setupFiles
各テストファイルの実行前に実行されるスクリプトを配列で指定する
ここで指定されているCheckBuildExists.jsでは main.prod.jsとrenderer.prod.jsの２つのファイルの存在チェックを行い、存在しなければ例外をThrowしてビルドコマンドを実行するメッセージを表示している
prettierフィールド
"prettier":{"overrides":[{"files":[".prettierrc",".babelrc",".eslintrc",".stylelintrc"],"options":{"parser":"json"}}],"singleQuote":true}コードの自動整形をしてくれるPrettierの定義フィールド
公式のconfigガイドを見ていく
https://prettier.io/docs/en/configuration.html
overrides
特定のファイルに対して異なるオプションを設定するための定義
通常prettierはファイルの拡張子からパーサーを判断してくれるが、rcファイルは拡張子がないためjsonとしてフォーマットさせる定義が書いてある
この手法はprettier公式のexampleにも書いてある
singleQuote
ダブルクォートの代わりにシングルクォートを使用する
stylelintフィールド
"stylelint":{"extends":["stylelint-config-standard","stylelint-config-prettier"]}css, scssのフォーマットチェックをしてくれるstylelintの定義 少ないけれど公式をちゃんと見る
https://stylelint.io/user-guide/configure
extends
継承する既存の設定ファイルの配列 後に書いたファイルの設定が優先して適用される
- stylelint-config-standard -> 60のルールを適用して推奨定義を拡張する
- stylelint-config-prettier -> prettierと競合する不必要なルールを無効にする
renovate
"renovate":{"extends":["bliss"]}npmパッケージの更新を補助するrenovateの定義フィールド
https://docs.renovatebot.com/configuration-options/#extends
extends
継承/使用するpresetを指定するファイル
指定されている'bliss'はrenovateの介入を最小限にする設定がされているらしい
https://github.com/amilajack/renovate-config-bliss
huskyフィールド
"husky":{"hooks":{"pre-commit":"lint-staged"}}gitの粗悪なcommitやpushを防いでくれるhuskyの定義フィールド
https://github.com/typicode/husky
hooks
何かを契機にコマンド実行するような定義をするフィールド
pre-commitはコミットの直前に動作させるコメントを定義できる
上述のlint-stagedを動作させている failした場合はcommitできない
終わりに
かなりボリュームはあったが、electronに限らずモダンWeb開発でよく使われるモジュールの定義が多数書かれていた。
ここに書かれている各モジュールについて理解することはelectron-react-boilerplateに限らず、多くの開発環境を作成、利用していくために役立つ知識になるでしょう。