フォーカスした内容でしたが、今回はJSのビルドとテストにフォーカスした入門記事です。テストを書くやらないことgulpまわりReact.jsCSSビルドまわり最終的なコードはこちらに上げておきました(すごく簡素な出来です)。sskyu/webpack-power-assert-jsdom-skeletonはじめに今年はReact.jsがJSerの中で定着した感がありました。Fluxの考え方を昇華させたReduxがFlux系フレームワークでデファクトになりそうな雰囲気を出しつつ、Reactive方面からはCycle.jsが登場してフロントエンドの技術は流れが早いですね。一方でビルド周りは去年からほとんど変わっていません。平たく言えば、Browserifyはシンプルな機能を提供していて、Webpackはフロントで必要そうな機能をたくさん提供しています。Webpackの方が多機能だから良さそうに見えますが、沢山の機能が密結合しているためバグが生まれやすいリスクがあります。BrowserifyでWebpackと同じことをしようとすると書き方を工夫しなくてはならず最初は難しいかもしれないですが、長期的に見ると機能がシンプルで拡張性のあるBrowserifyの方がメンテナンスしやすいかもしれません。Webpackを非難している訳ではないので、この記事ではWebpackを採用したケースで紹介していきます。検証している環境は下記のとおりです。v3.3.12プロジェクト作成ここからはプロジェクトを作っていく手順を書いていきます。入門記事なので経験者にはまどろっこしいかもしれません。"ISC"}ディレクトリを切る適当にディレクトリを切ります。ここはお好みでいいです。新規に作るので、初めから6系を使ってみます。変更点はこちらの記事が参考になりました。寄せることにしました。babel関連のモジュールをインストールします。下記の内容でプロジェクトルートに作成します。]}これでbabelまわりは一旦終わりです。Webpackの設定Webpackをインストールします。先ほどインストールを終えてます。設定系もES2015で書きます。記述することで、以降ES2015のシンタックスが使えるようになります。次の行では、configs以下に作るwebpackの設定を読み込むようにしました。ビルドの設定を変更する場合はそれぞれの環境ごとに設定ファイルを作成して、コマンドライン引数によって読み込むファイルを切り替えるようにすると良いです。違う環境でも共通の設定は当然あると思うので、baseとなるオブジェクト(設定)を作っておいて、環境ごとにオブジェクトを拡張するとメンテナンスがしやすいです。webpackConfig;これでES2015でソースを書く準備ができたのでソースを書いていきます。読み込む構成を作ります。クラス定義をexportするファイルは先頭を大文字で始めることにします。}}Webpackでビルドするwebpackコマンドでビルドできるか確認します。同様のことができるようになりました。Webサーバを立ち上げて開発するbuildタスクはjsファイルを作成するだけなので、スクリプトの動作を確認するためにはDOM上からscriptタグで読み込んで確認したいです。静的なhtmlをブラウザで読み込むよりも、Webサーバを立ち上げたほうが捗ります。いうモジュールがあるので、これを利用します。使うと任意のhtmlを読み込めるのでこれも利用します。使う設定を追記します。webpackConfig;こんな感じで、ベースとなるオブジェクトに設定を追加します。サーバーを立ち上げます。開いた状態で見れます。webpack-dev-serverは自動的にソースをwatchして差分ビルドを行ってくれます。追記すると良いでしょう。ユニットテストを書くやっと前置きが終わりました。今回、テストコードもES2015で書きますが、Webpack(babel-loader)を経由してビルドを行いません。構成で行ったほうがいいです。テスト基盤の作成ユニットテストに必要なモジュールをインストールします。babelによるトランスパイルとpower-assert用のコードへの変換を同時に行ってくれる大変便利なモジュールです。コマンドを実行する際にオプションで指定します。ファイルを作成します。コマンドを実行した際、自動的にオプションを読み込んでくれます。js:espower-babel/guessではユニットテストを書いていきます。以下のフォルダ構成と同じにします。テストコードはこんな感じになりました。});});あまり面白くないですね。APIを使っているので本来はテストをしにくいコードです。使うと仮想的なDOM環境をテストコード上に構築できます。いった変数を解釈できません。使う場合、node.js環境でも解釈できるように下記のようなコードをテストケース実行前に読み込む必要があります。いうモジュールがあるのでこれを利用します。v4以上が必要になります。利用したテストコードは下記のようになりました。(192ms)テストできました。phantomjsjsdomはphantomjsと違いDOMAPIを全て網羅しているわけではありません。いうAPIは今のところありません。Quoraこちらの回答を見ると、phantomjsに比べてjsdomのメリットは簡単なDOMのテストができること速度が速いことデメリットはDOMAPIを網羅していないDOMイベントまわりのテストが難しいブラウザ上でテストできないなどが上げられてます。個人的にはユニットテストはCLI上で行うものと割り切り、ブラウザ上でテストするならE2Eテストを作るのがいいと思います。みたいなコマンドを作ると思いますが、デプロイ前にはテストを走らせたいですよね。いう名前でタスクを定義します。すると事後処理を書けます。前後にネタコマンドを仕込むと幸せな気持ちになるかも。こちらの記事で知りました。yosuke-furukawa.hatenablog.com実行結果はこちら。こんなのが不意に表示されたらビビります。おわりに今年もなんとか投稿できて良かったです。参考に簡素化して紹介しました。ビルドまわりの設定はプロジェクトスタート時くらいしか触らないので、良いお手本を見つけてノウハウを吸収していきたいです。訳あってJavaScriptでのビット演算について調べてたのでその経...2014-03-09Browserifyの使い方について調べてみた最近Browserifyって単語を良く見るようになりました。(1)月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。