JSer infoでやったLTの資料

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

2. twitter: @joe_re
github: @joe-re
- 名前: じょー
- freeeという会社で働いています
- つい最近までクラウド会計やってました
- 今はクラウド給与やってます

4. 職業: gulp職人

6. すみません、僕はできません

7. この話のjs部分

8. Sprocketsを使い続けるの
つらい！

9. Sprocketsがやってくれること
とは
• CoffeeScript、Sassのコンパイル
• uglify
• minify
• fingerprintの付与
• 依存関係の定義(requireディレクティブの提供)
• などなど

10. Sprocketsを捨てたい理由
• フロントエンドのビルドツールの進化
• 基本的にgem化されていないと使えない(フロントエンドの進
化に追いつけない)
• フロント側までRailsにロックインされてしまうのが気持ち悪
い
• bowerが廃れた今、package.jsonに定義したnpmを直接
importして使いたい欲求がある

11. Sprocketsを捨てる2つの道

12. Railsのassets pipelineを一切
使わない！の道
• gulp等のビルドツールを使い、concat、
minify、uglify、fingerprint付与などの
Sprocketsさんがやっている仕事を全部奪う
• 成果物はPublic配下に出力する
• まさしく理想の世界！

13. Railsのassets pipelineを一切
使わない！の壁
• fingerprintの解決が難しい
• フロント側で単純に付与しただけでは、Rails
の asset_pathヘルパーが一切効かなくなる
• 一気にやらないといけない作業の量やばすぎ

14. フロント側の成果物をapp/assets
に吐き出す！の道
• concat、uglify、minify、fingerprintなどの処
理は従来通りSprocketsにお任せ！
• まだフロントで解決できないものは、とりあ
えずapp/assets配下にそのままコピーしてお
けば何とかなるので、徐々に作業可能

15. フロント側の成果物をapp/assets
に吐き出す！の壁
• 結局Sprocketsから脱却できてない
• 常にSprocketsとの良好な関係を
意識し続けなければプロダクトが死ぬ

16. 僕らはapp/assetsに成果物を
出力する道を選択した

17. ゆるい方針
• xxx-railsなGemは使わない
• 新しく書くコードはes2015で書けるようにし
よう
• npmでライブラリ管理しよう(goodbye
bower)

18. そこでgulpによるフロントエン
ドのビルドプロセスを導入

19. JavaScriptのビルド

20. Sprocketsのrequire

21. この順番を絶守！！！
Sprocketsのrequire

22. ちくしょう、Webpackだ！！

23. なんでBrowserifyじゃないの？
• 弊社のアプリケーションは複数のエントリー
ポイントがある
• Browserifyは開発時のwatchにおいて変更の
あったファイルのインクリメンタルビルドを
エントリーポイントごとに行う仕組みを構築
するのが大変

24. Webpackならwatchオプショ
ンにtrueを渡すだけ！！
https://webpack.github.io/docs/tutorials/getting-
started/#watch-mode

25. 得たもの
• ライブラリはnpmで管理(これまで使っていた
bower(bower-rails)とはオサラバ！)
• Babelによるトランスパイル(ES2015)
• CoffeeScriptのトランスパイル
• ES6-modules、CommonJSによる依存解決

26. さぁこれからはテストを
書いていくぞ！

27. React + Fluxの導入！

28. Reduxは使わないぞ

29. facebook/utilの
Reduce Storeだ！

30. おわり