Upgrade to Pro — share decks privately, control downloads, hide ads and more …

なぜSprocketsを捨てるべきか / Why do I want to throw away sprockets?

B72422afc5f3ffc844f672b59122e16d?s=47 joe_re
June 27, 2016

なぜSprocketsを捨てるべきか / Why do I want to throw away sprockets?

西日暮里.rb 2周年記念 LT
https://nishinipporirb.doorkeeper.jp/events/46772

B72422afc5f3ffc844f672b59122e16d?s=128

joe_re

June 27, 2016
Tweet

Transcript

  1. なぜSprockets を 捨てるべきか @joe_re

  2. Who am I? twitter: @joe_re github: @joe­re working in freee.K.K

    are Saiko!
  3. 職業: Sprockets 捨てたいマン

  4. 前回までのあらすじ http://www.slideshare.net/masatonoguchi169/sprockets­ 49965435

  5. なぜSprockets を捨てたいのか。 今回は少しエモ寄りの話をします。

  6. 感情的な部分は個人の見解なので、 そういう感じでご理解ください。

  7. Sprockets とは何か Ruby 製のアセットプリプロセッサ Rails3.1 から導入された AltJS やsass のコンパイル concat、minify、md5

    フィンガー プリント 独自の依存解決を提供( 後述)
  8. なんで捨てたいのか( 技術寄り) フロントエンド側のツー ルの成熟 (babel, brawsarify, webpack, etc...) Gem 化されていることが前提になる

    ( フロントの進化に追従していくのは気合が必要) Sprockets を通すことによるビルド速度の低下 独自依存解決(require) つらいし、 ロックインされたくない
  9. なんで捨てたいのか( 技術寄り) フロントエンド側のツー ルの成熟 (babel, brawsarify, webpack, etc...) Gem 化されていることが前提になる

    ( フロントの進化に追従していくのは気合が必要) Sprockets を通すことによるビルド速度の低下 独自依存解決(require) つらいし、 ロックインされたくない
  10. Speockets の依存解決方法 # b a r . j s .

    c o f f e e # i n i t i a l i z e 的なやつで先に ` w i n d o w . f r e e e = { } ` をやっておく c l a s s B a r e x t e n d s f r e e e . F o o h o g e M e t h o d : - > # s o m e p r o c e s s e s w i n d o w . f r e e e . B a r = B a r / / f o o b a r . j s / / = r e q u i r e f o o / / = r e q u i r e b a r require の順番を絶対に死守しないと動かないぞ
  11. でもこれだけなら browseryfy­rails とかでも なんとかなる https://github.com/browserify­rails/browserify­rails

  12. なんで捨てたいのか( 気持ち寄り) 時は経ちフロントエンド側のツー ルは成熟し、 Sprockets の庇護はもはや必要なくなった フロント側のスタックでlint とか型チェックとか 自由にやりたい(erb になってると困難)

    サー バ側のコンテキストが フロントに持ち込めてしまうのが気持ち悪い ( そのせいでフロント側のユニットテストが書きづらい)
  13. ともすれば人はこんなerb を作ってしまう # e r b _ s a m

    p l e . j s . e r b e x p o r t d e f a u l t c l a s s E r b S a m p l e { h o g e ( ) { r e t u r n < % = a s s e t _ p a t h ( ' h o g e . g i f ' ) % > ; } }
  14. それはもともと フロントの仕事です これのせいでそのままeslint とかかけられない webpack にかける対象からこれだけ外さないといけない つらい

  15. とはいえRails に乗る以上は、 Rails にassets のpath を伝えないと いけない

  16. そこでフロント側のビルド時に manifest.json を生成するというアプロー チ https://github.com/danethurber/webpack­manifest­plugin https://github.com/waka/gulp­sprockets

  17. かくして僕らは完全にSprockets から離れられた?

  18. というわけはなく i18n などのサー バ側とどうしても共有したい情報はある フロント側でassets のパスを扱いたい時にどうする? などなど 参考: @kuy /

    Rails+webpack の落ち穂拾い https://speakerdeck.com/kuy/rails­plus­webpackfalseluo­tisui­ shi­i
  19. まとめ

  20. Sprockets による問題を 一言で表すと

  21. 本来フロントだけだったら サクッとやれるのに!

  22. みたいな何かが発生しうるということ

  23. たとえば ライブラリのバー ジョンアップがGem に依存してしまう ES2015­modules(file 単位でrequire) ができない unit test を走らせたいだけなのに、

    わざわざRails 立ち上げないといけないの ライブラリは全てnpm で管理して、JS のエコシステムに 乗りたい人生だった
  24. 必ずしも全ての環境に 問題が発生するわけ ではない

  25. 問題になっていないのであれば 無理をすることもない

  26. ただし僕には Sprockets は 許容できない

  27. 信念

  28. 大事なのは強い心と やっていく気持ち

  29. ありがとうございました