Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

職業: Sprockets 捨てたいマン

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Sprockets とは何か Ruby 製のアセットプリプロセッサ Rails3.1 から導入された AltJS やsass のコンパイル concat、minify、md5 フィンガー プリント 独自の依存解決を提供( 後述)

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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 の順番を絶対に死守しないと動かないぞ

Slide 11

Slide 11 text

でもこれだけなら browseryfy­rails とかでも なんとかなる https://github.com/browserify­rails/browserify­rails

Slide 12

Slide 12 text

なんで捨てたいのか( 気持ち寄り) 時は経ちフロントエンド側のツー ルは成熟し、 Sprockets の庇護はもはや必要なくなった フロント側のスタックでlint とか型チェックとか 自由にやりたい(erb になってると困難) サー バ側のコンテキストが フロントに持ち込めてしまうのが気持ち悪い ( そのせいでフロント側のユニットテストが書きづらい)

Slide 13

Slide 13 text

ともすれば人はこんな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 ' ) % > ; } }

Slide 14

Slide 14 text

それはもともと フロントの仕事です これのせいでそのままeslint とかかけられない webpack にかける対象からこれだけ外さないといけない つらい

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

というわけはなく i18n などのサー バ側とどうしても共有したい情報はある フロント側でassets のパスを扱いたい時にどうする? などなど 参考: @kuy / Rails+webpack の落ち穂拾い https://speakerdeck.com/kuy/rails­plus­webpackfalseluo­tisui­ shi­i

Slide 19

Slide 19 text

まとめ

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

たとえば ライブラリのバー ジョンアップがGem に依存してしまう ES2015­modules(file 単位でrequire) ができない unit test を走らせたいだけなのに、 わざわざRails 立ち上げないといけないの ライブラリは全てnpm で管理して、JS のエコシステムに 乗りたい人生だった

Slide 24

Slide 24 text

必ずしも全ての環境に 問題が発生するわけ ではない

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

信念

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

ありがとうございました