読者です 読者をやめる 読者になる 読者になる

yutaponのブログ

javascript界隈の興味あるネタを備忘録的に残しておく場所

webpack+babel-loader+power-assert+jsdomでフロントエンド開発環境を作る

webpack jsdom tdd build

この記事は JavaScript Advent Calendar 2015 10日目の記事です。

去年は主に gulp にフォーカスした内容でしたが、今回はJSのビルドとテストにフォーカスした入門記事です。

  • やること
    • ES2015で書いたコードをWebpackでビルドする
      • babel@6系を使う
    • Mocha + power-assert + jsdom でテストを書く
  • やらないこと
    • gulpまわり
    • React.js
    • CSSビルドまわり

最終的なコードはこちらに上げておきました(すごく簡素な出来です)。

sskyu/webpack-power-assert-jsdom-skeleton · GitHub

はじめに

今年は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を採用したケースで紹介していきます。

続きを読む

ES6構文の ... (Spread operator)と { prop } (shorthand property names)について

es6

昨日twitter見てたらこんなのが流れていまして

何だこの書き方〜と気になったので調べてみた。

続きを読む