これまで Web フロントエンドや Electron の JavaScript ビルドには Browserify と Babel を使用してきた。しかし Browserify の開発は停滞している。現在は個人から org 運営へ移管しており browserify/discuss にて開発者の募集や議論もおこなわれているものの、往時の勢いはない。

私としては CLI のみで完結して設定を package.json に集約しやすい点から Bundler の中では Browserify 推しだった。しかし今後のことを考えると webpack に移行したほうがよいと判断せざるをえない。

というわけで Electron プロジェクトの開発環境に webpack を導入してみた。以下はその覚書。

• サンプル プロジェクト akabekobeko/examples-electron

Browserify + Babel によるビルド

移行前に Browserify + Babel でおこなっていたビルド設定は以下。package.json 内で完結している。

{
  "babel": {
    "presets": [
      ["env", {"targets": {"electron": "1.7"}}],
      "react"
    ],
    "env": {
      "development": {
        "presets": [
          "power-assert"
        ]
      }
    }
  },
  "scripts": {
    "build:js-main": "browserify -t [ babelify ] ./src/js/main/Main.js --exclude electron --im --no-detect-globals --node -d | exorcist --base ./src/assets ./src/assets/main.js.map > ./src/assets/main.js",
    "build:js-renderer": "browserify -t [ babelify ] ./src/js/renderer/App.js --exclude electron -d | exorcist --base ./src/assets ./src/assets/renderer.js.map > ./src/assets/renderer.js",

    "watch:js-main": "watchify -v -t [ babelify ] ./src/js/main/Main.js --exclude electron --im --no-detect-globals --node -o \"exorcist --base ./src/assets ./src/assets/main.js.map > ./src/assets/main.js\" -d",
    "watch:js-renderer": "watchify -v -t [ babelify ] ./src/js/renderer/App.js --exclude electron -o \"exorcist --base ./src/assets ./src/assets/renderer.js.map > ./src/assets/renderer.js\" -d",

    "release:js-main": "cross-env NODE_ENV=production browserify -t [ babelify ] ./src/js/main/Main.js --exclude electron --im --no-detect-globals --node | uglifyjs -c warnings=false -m -d DEBUG=false > ./dist/src/assets/main.js",
    "release:js-renderer": "cross-env NODE_ENV=production browserify -t [ babelify ] ./src/js/renderer/App.js --exclude electron | uglifyjs -c warnings=false -m -d DEBUG=false > ./dist/src/assets/renderer.js"
  }
}

Main/Renderer プロセスで個別に Bundle。目的ごとに接頭辞で分類しており、それぞれ

• build: 開発用ビルド
• watch: 開発用ビルド、ファイル監視して更新検知したら差分ビルドする
• release: リリース用ビルド

となる。かなり長くて複雑なオプションを指定しているが、これは Electron や Node のランタイム モジュールを除外するなどの処理が必要なため。詳細は

• Electron を試す - 開発環境の構築

を参照のこと。webpack では同等かそれ以上の Bundle 処理を目指す。

webpack

まずは必要な npm のインストール。

$ npm i -D webpack babel-loader babel-minify-webpack-plugin
$ npm i -D babel-core babel-preset-env babel-preset-react

それぞれの役割をまとめる。

Babel は Bundler から独立しているため、Browserify 時代の設定をそのまま流用可能。

webpack.config.babel.js

webpack の設定は webpack.config.js というファイルに JavaScript として実装。この処理を ES2015 以降へ対応させたい場合は Babel をインストールしたうえで webpack.config.babel.js というファイル名にする。今回はこちらでゆく。

import WebPack from 'webpack'
import MinifyPlugin from 'babel-minify-webpack-plugin'

export default (env) => {
  const MAIN = env && env.main
  const PROD = env && env.prod

  return {
    target: MAIN ? 'electron-main' : 'web',
    entry: MAIN ? './src/js/main/App.js' : './src/js/renderer/App.js',
    output: {
      path: PROD ? `${__dirname}/dist/src/assets` : `${__dirname}/src/assets`,
      filename: MAIN ? 'main.js' : 'renderer.js'
    },
    devtool: PROD ? '' : 'source-map',
    node: {
      __dirname: false,
      __filename: false
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: {
            loader: 'babel-loader'
          }
        }
      ]
    },
    plugins: PROD ? [
      new MinifyPlugin({
        replace: {
          'replacements': [
            {
              'identifierName': 'DEBUG',
              'replacement': {
                'type': 'numericLiteral',
                'value': 0
              }
            }
          ]
        }
      }, {}),
      new WebPack.DefinePlugin({
        'process.env.NODE_ENV': JSON.stringify('production')
      })
    ] : [
      // development
    ]
  }
}

内容について解説する。エントリー ポイントを export default (env) => {...} としているが、これは Environment Variables を使用するためのもの。

Electron は少なくとも Main/Renderer の 2 種類をビルドする必要がある。それらを更に開発用とリリース用にわけるので単純に設定ファイルを定義すると 4 種類もの分岐が発生するうえ、設定や処理の大半は共通。

そのため設定ファイルは共通で外部引数によって処理を分岐する方式を採用した。Environment Variables はこの用途にうってつけの機能である。webpack を CLI から実行する際に

$ webpack --env.prod --env.main

のように --env.XXXX 形式の引数を与えると webpack のエントリー ポイントにした関数の第一引数に展開される。値名だけだと Boolean で true となり --env.XXXX=1 のように明示的に内容を指定することも可能。これを利用して npm-scripts 側は

{
  "scripts": {
    "build:js-main": "webpack --env.main",
    "build:js-renderer": "webpack",
    "watch:js-main": "webpack --env.main --watch",
    "watch:js-renderer": "webpack --watch",
    "release:js-main": "webpack --env.prod --env.main",
    "release:js-renderer": "webpack --env.prod"
  }
}

となる。--env.main により Main/Renderer、--env.prod でリリースと開発版を分岐している。これを受けて webpack 側は

export default (env) => {
  const MAIN = env && env.main
  const PROD = env && env.prod
}

とする。env を直に使わず別の変数に格納している理由は --env.XXXX が未指定だと undefined になるため env.XXXX を判定できないから。参照部分ごとに env の存在をチェックするのは冗長なので事前チェックして変数化しておく。

__dirname と __filename

コード中に __dirname と __filename が含まれていると webpack がコンテキストにあわせて解決しようとする。しかしこれは Node として実行される Main プロセスにおいて問題を引き起こす。例えば BrowserWindow.loadURL のパスに指定すると正しくファイルを読み込めない。そのため無効化して Node として処理されるようにする。

{
  node: {
    __dirname: false,
    __filename: false
  }
}

Electron だと __filename を使用することはなさそう。しかし参照したくなったときに Node と異なる動作をすると厄介なので、ついでに設定しておく。これで開発版だけでなくリソースを asar にパッケージ化したリリース版イメージでも想定どおりパスが処理される。Renderer ではそもそも __dirname などを参照することはないが、使用しないものについて webpack 設定を分岐する意味はないため Main/Renderer 共通とした。

target

webpack の Target 設定はビルド対象の仕向けを指定することで import/require を適切に処理してくれる。Electron 向けとしては

の 2 種類をサポート。Main プロセスのビルドでそのまま Node/Electron のモジュールを Bundle すると参照エラーになる。よって electron-main を指定して実行時に参照解決されるようにしておく。

Renderer プロセスについては electron-renderer か web を指定。前者だと webpack プラグインと組み合わせることで Node/Electron モジュールの参照を適切に処理してくれる。しかし私は Renderer 側で Node/Electron モジュールを使用させない主義のため、Main プロセスとの通信に必須の ipcRenderer に限定している。

Node/Electron の機能が必要ならば Main プロセスにリクエストすればよい。処理結果も Main プロセスから Renderer プロセス側へ返せる。よって Renderer の target は web とした。

{
  target: MAIN ? 'electron-main' : 'web'
}

Renderer の require について。ipcRenderer を使用するために require が必要となる。しかしこれは直に使用せず

const ipc = window.require('electron').ipcRenderer
ipc.send('message', 'Hello world!!')

というように window に属するものとして明示的に呼び出す。こうすると Web フロントエンドとしての require or import と Node/Electron 由来の参照を明確に区別できる。そのため target が web でも問題ない。これは Borwserify 時代からの対応だが設計面でも Bundler 処理的にも好ましいと考えており、実際に webpack でもそのまま維持できた。

minify と環境変数 production

使用してる npm の項でも触れたが minify に babel-minify-webpack-plugin を使用している。これは babel-minify の wrapper。かつて babili と呼ばれており、本ブログでも

• babel-preset-babili を試す

で紹介した。Babel ファミリーのツールだけあって ES.next を考慮した minify を実行してくれる。Browserify と組み合わせると Babel (babelify) から先に実行されるため

• Bundler 部分のコードが minify されない
• 単独 CLI だと Babel 処理に組み込めない

といった問題があってイマイチだったのだが webpack だと Bundler 処理の一部として実行されるため、問題はすべて解決されている。webpack の設定としては

{
  plugins: PROD ? [
    new MinifyPlugin({
      replace: {
        'replacements': [
          {
            'identifierName': 'DEBUG',
            'replacement': {
              'type': 'numericLiteral',
              'value': 0
            }
          }
        ]
      }
    }, {}),
    new WebPack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production')
    })
  ] : [
    // development
  ]
}

となる。第一引数に babel-minify のパラメーター、第二引数でプラグイン独自のパラメーターを指定。今回はデバッグ時の if-def 変数 DEBUG を無効化するようにした。この変数については

• Electron を試す 2 - パッケージ化におけるプラットフォーム固有処理とコンパイル分岐

で言及しているので詳細はそちらを参照のこと。簡単に要約すると

if (DEBUG) {
  console.log('DEBUG MODE!!!')
}

みたいにデバッグ専用の処理を定義しておき、リリース用ビルドで処理をまるごと除去するためのもの。古式ゆかしいコンパイル分岐と pre-process である。

リリース用ビルドにおける production 環境変数について。

npm によっては process.env.NODE_ENV が development か production であることを判定してコンパイル分岐してる。本来ならさきほど紹介した例もこの方法で実装すべきだったが、それは将来の課題ということで。process.env.NODE_ENV を変更する場合、CLI 実行であれば cross-env か webpack 処理で代入することになる。これは標準プラグイン DefinePlugin で対応するほうがよいだろう。

DefinePlugin にしておけば他に環境変数を設定したいときも、ここへ局所化できる。webpack 公式でも Production の Specify the Environment でこの方法を紹介している。

これらの設定で minify すると適切に圧縮され、mangle による副産物としての難読化もおこなわれていることが確認できるはず。

original-fs

音楽プレーヤーのサンプルで Electron の original-fs を参照していたのだが、webpack の target を electron-main にしていてもこれがエラーになる。

ERROR in ./src/js/main/model/MusicMetadataReader.js
Module not found: Error: Can't resolve 'original-fs' in '.../examples-electron/audio-player/src/js/main/model'

Electron は 2 種類の fs を提供しており original-fs は asar をサポートしない Node 本来のもの。その処理を実装していた当時は Electron 版 fs だとなにか問題が起きると勘違いして明示的に original-fs を使用したほうがよいと考えていた。

しかし asar に関する処理をしないのであれば fs でもよいため、そのように修正。original-fs が本当に必要となったときは困りそうだから、後で webpack の issues を探してこの問題が報告されていなければレポートを挙げるかもしれない。

まとめ

webpack を使用しはじめたのは最近であること、Electron アプリで Bundler 処理する場合は Node と Web フロントエンドの両方を考慮しなければならないことから、かなり不安があった。

しかし Browserify 関連のツール チェインで要件を洗い出せていたのは大きかった。この種のツールに戸惑うのは要件が定まっていないからである。先に目的を明確にしていれば利用や代替はさほど難しくない。必要最小でよいのだし。今回もそんな感じでわりとスムーズに移行できた。

あと webpack の Environment Variables 機能のおかげで想像よりもずっとシンプルな設定にできて嬉しい。webpack を npm-scripts から実行する派ならファイル分岐を減らすのに効果抜群なのでかなりオススメ。

そういえば Electron サンプルとして examples-electron を公開してるけど、ずっと 3 プロジェクトなのもさみしいので簡易ファイラーを追加したいと考えてる。前から自分用に画像ビューアーがほしいと思ってて、その習作としてもよいのでは？というのがその理由。

ただ examples-electron は他にも

• Flux を material-flux から redux か almin に移行
  • 機能的に不満はないが Browserify から webpack へ移行したように一般的で勢いのあるものにしたい
  • redux は既に一般教養となってるから好みとは別に触れておくべきだろう
  • redux を class base にしたような almin も興味ある、なにしろ material-flux と同じ作者だ
• AltCSS を Stylus 以外へ移行
  • AltCSS 系では Stylus が最も気に入っているけど開発側の熱は失われかけているため移行を検討したい
  • 2017/12 時点だと postcss が有力候補だろうか？
  • ただし Stylus 単体で実現していた機能を postcss のプラグインをかき集めて実現するのは面倒そうだ
  • 大きな問題が起きるまでは Stylus でよい、という考えもある
• Test Runner を ava へ移行
  • 現在は mocha だが、これと組み合わせてる power-assert を ava が内部利用してるので出力機能としては同等
  • ava の機能としては並列実行に惹かれる
  • mocha も mocha.parallel があるけど ava だと単体で多機能なのでツール チェインを削減できる

といった課題がある。足回りを先にしたほうが生産性あがるのでサンプル追加より環境面を優先するかもしれない。その場合 redux/alumin 移行が作業と学習量として重く時間かかりそう。