webpack-dev-server の後継らしい webpack-serve について調べた

追記（2018-09-19）

webpack-serve が DEPRECATED となり webpack-dev-server の利用が推奨されています。
README には

DEPRECATED. Please use webpack-dev-server (he is in support and update mode again). Feel free to create a issue if some features are not implemented in webpack-dev-server.

との記載があるので、webpack-dev-server の開発が再開したようです。

DEPRECATED となった理由についても記載されているので、興味のある方は GitHub のリポジトリを御覧ください。
webpack-serve/README.md at edaf28c6c935c3e29d26dbb02a9d6b672cc5148a · webpack-contrib/webpack-serve · GitHub

追記（2018-05-20）

webpack-serve が v1.0 になったので、以下の記事を書きました。

yami-beta.hateblo.jp

---

開発用サーバとして使われている webpack-dev-server ですが、README に記載されているようにメンテナンスモードに入っています。

Please note that webpack-dev-server is presently in a maintenance-only mode and will not be accepting any additional features in the near term.

github.com

同じく README には webpack-serve へのリンクがあり、こちらが後継の開発サーバのようです。

github.com

webpack-serve

（以下は v0.2.0 時点の情報です）

webpack-serve は webpack-dev-server と同じく開発用サーバですが WebSocket や koa-static を用いている部分が特徴です。
webpack-serve 自体に機能を持たせるのではなく Add-on という形で、外から必要な機能を追加していく形式になっており docs/addons に幾つかの設定ファイルのサンプルが用意されています。

webpack-serve は CLI からもスクリプトとしても利用できるようになっています。
CLI から用いる場合、以下のように webpack の設定ファイルを明示的に指定する必要があります。
設定ファイルを指定しない場合は、webpack 4 と同様に no config でのビルドを行います。

{
  "scripts": {
    "serve": "webpack-serve --config webpack.config.js"
  }
}

また、webpack-serve 用の設定を記述する方法も複数用意されています。
webpack-contrib/webpack-serve#webpack-serve-config

webpack-serve を試して気になったこと

webpack では設定ファイルの記述方法として function を用いることが出来ますが、webpack-serve では v0.2.0 時点で非推奨となっています。
（この理由も README 内に記載されています）

module.exports = (env, argv) => {
  return {
    mode: "development",
    module: {
      // ...
    }
  };
};

一方で webpack 4 から --mode を指定するようになりましたが、この値を webpack.config.js 内で参照する方法が現状 function の引数で受け取る方法しかありません。
（もし、他の方法がある場合は是非教えてください）

github.com

webpack.config.js 内で development と production で設定を分岐させているプロジェクトでは、v3 から v4 への移行時に process.env.NODE_ENV から argv.mode を用いる方法へ書き換えた場合、webpack-serve で非推奨となっている function 形式で設定ファイルを記述することになってしまいます。

感想

まだ Add-on のサンプルが少なかったりするので、すぐに webpack-dev-server から移行する必要はなさそうですが、適時チェックしておくと良さそうです。

自作プラグインの webpack v4 対応をしました

自作の license-info-webpack-plugin を webpack v4 に対応させました。

www.npmjs.com

yami-beta.hateblo.jp

手順

webpack v4 対応する上でそのままでは動かないことは容易に予想できていたので、以下の順で段階的に対応を進めました。

1. webpack v3 用のテストを書く github.com
2. 複数バージョンの webpack でテスト出来るようにテストコードを修正 github.com
3. webpack v4 用のテストを書き、v3, v4 の両対応をする github.com

webpack v4 での変更点

plugin や loader における対応は、以下のページにまとまっています。

medium.com

一番大きな変更点は

// webpack v3
compiler.plugin("compilation", compilation => {
  // ...
})

が

// webpack v4
compiler.hooks.compilation.tap({ name: "plugin-name" }, compilation => {
  // ...
})

になったことです。

従来の compiler.plugin() の第一引数に指定していた文字列が compiler.hooks のプロパティになっています。 このプロパティは、従来の kebab-case を camelCase にすることで対応できます。

また tap 以外に tapAsync , tapPromise でプラグイン処理を挟み込む事ができます。

v3, v4 両対応するには、分岐するのが一番シンプルなので

if (compiler.hooks) {
  // webpack v4
} else {
  // webpack v3
}

というような処理になるかと思います。

感想

自分のプラグインはさほど大きな対応をする必要は無かったのですが、Chunk graph や ChunkGroups あたりに大きな変更が入っているので、この辺りを触っているプラグインは大変そうな予感がしています。

webpack v4 対応にあたって uglifyjs-webpack-plugin や webpack/webpack リポジトリ内にある プラグイン の変更履歴を参考にしました。