webpack+babel-loader+power-assert+jsdomでフロントエンド開発環境を作る
この記事は JavaScript Advent Calendar 2015 10日目の記事です。
去年は主に gulp にフォーカスした内容でしたが、今回はJSのビルドとテストにフォーカスした入門記事です。
- やること
- ES2015で書いたコードをWebpackでビルドする
- babel@6系を使う
- Mocha + power-assert + jsdom でテストを書く
- ES2015で書いたコードをWebpackでビルドする
- やらないこと
- gulpまわり
- React.js
- CSSビルドまわり
最終的なコードはこちらに上げておきました(すごく簡素な出来です)。
GitHub - sskyu/webpack-power-assert-jsdom-skeleton
はじめに
今年はReact.jsがJSerの中で定着した感がありました。
Fluxの考え方を昇華させたReduxがFlux系フレームワークでデファクトになりそうな雰囲気を出しつつ、Reactive方面からはCycle.jsが登場してフロントエンドの技術は流れが早いですね。
一方でビルド周りは去年からほとんど変わっていません。
ES2015のシンタックスを使いたい場合は babel.js でトランスパイルをして、ブラウザ向けのビルドに browserify または webpack を使います。
Browserify vs Webpack
それぞれの特徴を列挙してみると
- Browserify
- コアはCommonJS形式のモジュールをブラウザでも扱えるようにすること
- 単一のファイルを出力する
- 工夫すれば複数ファイルの出力も可能
- 他の機能はプラグインとして提供される
- e.g. babelify, coffeeify, etc...
- Webpack
- デフォルトで多機能
- CommonJS, AMD形式のモジュールをブラウザでも扱えるようにする
- CSSのビルド
- 複数ファイルの出力がデフォルトでサポートされている
- loaderを加えることで様々な機能を加えることが可能
- JSファイルからCSSやImageを読み込むことが可能
- デフォルトで多機能
平たく言えば、Browserifyはシンプルな機能を提供していて、Webpackはフロントで必要そうな機能をたくさん提供しています。
Webpackの方が多機能だから良さそうに見えますが、沢山の機能が密結合しているためバグが生まれやすいリスクがあります。
BrowserifyでWebpackと同じことをしようとすると書き方を工夫しなくてはならず最初は難しいかもしれないですが、長期的に見ると機能がシンプルで拡張性のあるBrowserifyの方がメンテナンスしやすいかもしれません。
Webpackを非難している訳ではないので、この記事ではWebpackを採用したケースで紹介していきます。
続きを読む