RailsのRailから
解放される始めの一歩
@joe_re
twitter: @joe_re

github: @joe-re
- 名前: じょー
- freeeという会社で働いています
- つい最近までクラウド会計やってました
- 今はクラウド給与やってます
職業: gulp職人
すみません、僕はできません
この話のjs部分
Sprocketsを使い続けるの
つらい!
Sprocketsがやってくれること
とは
• CoffeeScript、Sassのコンパイル
• uglify
• minify
• fingerprintの付与
• 依存関係の定義(requireディレクティブの提供)
• などなど
Sprocketsを捨てたい理由
• フロントエンドのビルドツールの進化
• 基本的にgem化されていないと使えない(フロントエンドの進
化に追いつけない)
• フロント側までRailsにロックインされてしまうのが気持ち悪
い
• bowerが廃れた今、package.jsonに定義したnpmを直接
importして使いたい欲求がある
Sprocketsを捨てる2つの道
Railsのassets pipelineを一切
使わない!の道
• gulp等のビルドツールを使い、concat、
minify、uglify、fingerprint付与などの
Sprocketsさんがやっている仕事を全部奪う
• 成果物はPublic配下に出力する
• まさしく理想の世界!
Railsのassets pipelineを一切
使わない!の壁
• fingerprintの解決が難しい
• フロント側で単純に付与しただけでは、Rails
の asset_pathヘルパーが一切効かなくなる
• 一気にやらないといけない作業の量やばすぎ
フロント側の成果物をapp/assets
に吐き出す!の道
• concat、uglify、minify、fingerprintなどの処
理は従来通りSprocketsにお任せ!
• まだフロントで解決できないものは、とりあ
えずapp/assets配下にそのままコピーしてお
けば何とかなるので、徐々に作業可能
フロント側の成果物をapp/assets
に吐き出す!の壁
• 結局Sprocketsから脱却できてない
• 常にSprocketsとの良好な関係を

意識し続けなければプロダクトが死ぬ
僕らはapp/assetsに成果物を
出力する道を選択した
ゆるい方針
• xxx-railsなGemは使わない
• 新しく書くコードはes2015で書けるようにし
よう
• npmでライブラリ管理しよう(goodbye
bower)
そこでgulpによるフロントエン
ドのビルドプロセスを導入
JavaScriptのビルド
Sprocketsのrequire
この順番を絶守!!!
Sprocketsのrequire
ちくしょう、Webpackだ!!
なんでBrowserifyじゃないの?
• 弊社のアプリケーションは複数のエントリー
ポイントがある
• Browserifyは開発時のwatchにおいて変更の
あったファイルのインクリメンタルビルドを
エントリーポイントごとに行う仕組みを構築
するのが大変
Webpackならwatchオプショ
ンにtrueを渡すだけ!!
https://webpack.github.io/docs/tutorials/getting-
started/#watch-mode
得たもの
• ライブラリはnpmで管理(これまで使っていた
bower(bower-rails)とはオサラバ!)
• Babelによるトランスパイル(ES2015)
• CoffeeScriptのトランスパイル
• ES6-modules、CommonJSによる依存解決
さぁこれからはテストを

書いていくぞ!
React + Fluxの導入!
Reduxは使わないぞ
facebook/utilの
Reduce Storeだ!
おわり

RailsのRailから解放される始めの一歩