Webpackがいろいろと辛い

この記事を書いた経緯はというと、既存のコードにテストの環境を整えようとしたところでいろいろとWebpack関連で詰まったため記事にした。

既存のコードはWebpackでビルドされていて、loaderなど依存が多かったため、テストもWebpackで解決するのが早いだろうと考えたところからはじまった。

しばしばパッケージの解決に失敗する

Webpackでbundlingを行っていたのだが、テストの環境を導入しようとしてsinonを利用しようとしたら、エラーが出た。

調べてみたらすでにissueに上がっており、AMD対応の部分を削除して対応したforkが上がっていた。

しかし、そのforkは最新ではなかったため、fork元の最新をマージしたforkを作って対応した。

こんな感じにうまくbundlingできないものが多く、いちいち対応してたら非効率である。

Webpackの代替策として挙げられるのがBrowserifyである。

その違いは思想にあるが、今回は詰まった点を軸にして書き連ねる。

Webpackはグローバルが扱いにくい。expose-loaderなど対応策は無くはない。そとそもグローバル汚染を避けることをbundlingの目的としていることもあり、本末転倒感あるが、テストなどでアサーションをグローバルに置きたいといったこともある。

BrowserifyではdetectGlobalsオプションで解決可能である。そもそもwebpackで解決したものをnode環境で実行するというのは方向性が違う感じはある。

またnode_modulesをbundlingせず、通常のcommonjsとしてrequireするということもwebpackでは一般的にできるわけではないようだ。browserifyではbundleExternalオプションで解決できる。

webpackにtargetというオプションが存在し、nodeやatomといった選択肢がある。しかし、先述のsinonのbundlingは解決できなかった。イマイチこのオプションは把握していない。

Webpackにはいろいろと問題が多いことが今回わかった。既存のコードを変更してbrowserifyへの移行を検討しようかと考えている。

今回、あまり調査せずただ結果だけを並べてWebpackはクソ的な記事を書いてしまったが、これ以上、依存パッケージの解決に失敗するごとにパッチを書くのは非効率だと感じたところもあり、Browserifyへの移行の方が今後のためにも良いと判断したためだ。