いうVR卓球で夜な夜な練習していたら、少しほっそりとしてきたきがします。生まれてこの会社に入るまでRailsに触ったことが無かったんですが、いざ使ってみるとSprockets辛すぎて、よくみんな平然とした顔でコーディングしてるなと思って、聞いてみたらやっぱり辛いらしいってことなんで、普通のJSの開発が出来るように工夫してみた。いうのが本日のお話となります。チームメンバの石井がきっとやります。4.2.7.1Sprocketsでコンパイルされたapplication.jsが10万行ぐらいあるばりばりjQueryJSはCIされてない既存の類似した話そんなに目新しいはなしでもなく、過去に同様のチャレンジを行っている方がいます。いくつかピックアップしてみました。採用した技術などの細かい点では本稿と違うところがあるので、参考になるかと思います。変わってしまうので現在に限った話で言うと大体以下のようになります。更新していける」ことも重要かなと考えます。最終的に採用された技術browserifyでバンドルbabelでesの新しい記法やjsxmochaでテストassertはpower-assertgulpサンプルプロジェクトゴールに向かうためにRailsプロジェクト上に加えた変更を専用のリポジトリで再現しました。いうページが用意してあります。PRを元にやったことを段階的に説明していきます。initをのぞくと最初にやらなければいけないのは、「何のファイルをどのディレクトリに置くか?」を決めることでした。次の図は、どのようなディレクトリ構成でファイルを管理するのかを示したものです。多少プロダクトごとに差異はありますがだいたいこのような配置を取ることにしました。/client/spec/examples/components/HelloExample.jsreactを使ったページを想定してこのタイミングでbabelなどの設定をしています。この段階ではユニットテストは出来ますが、ブラウザ用のJSはビルドできません。gulpタスク本番で読み込むためにビルドタスクを実装します。よりプロダクションコードを生成できるようになりました。あとwatchも出来るようになりました。babelの構成だと思うのでここでは省略します。bustingのためにbuildしたファイルにdigestをつけます。いうgulpのpluginを使っているだけでとくに工夫はありません。Railsから読み込むここまででjs側でやることはほぼ終わりました。一方でscriptタグはまだハードコーディングでとても継続的に運用出来るものではありません。ApplicationHelperの修正いつまでもハードコーディングするわけにいかないので仕組み化します。生成しておく対応するjsが無かったら何もしないこれで新しくページが増えたときも命名規則に従ってjsファイルを追加すれば自動的に読み込まれるようになりました。digestつけなければ良いのでは?」というもっともな意見があると思います。それは発想としてはシンプルですし、Sprocketsなどでも採用されている方法でいっけんスジのいい方法だと思えます。冷静に考えて「本番と開発中で別々のロジックが動く」のってリスクを感じませんか?もちろん採用実績の豊富な仕組みならば信用できます。今回は自分たちで実装するロジックです。この点においてより堅実な方法は無いか?とメンバーからの指摘と議論を経た結果がこの仕組です。結果的により安心して保守運用していける構成になったかな思います。リリースとCIここまでくればあとは本番デプロイ時にjsをビルドするのと、CIすれば終わりです。既存のデプロイフローやCIになじみやすい方法を取りました。差分まとめ現状の普通を目指して、sprocketsの横にそっと環境構築をしました。大きくnode側でやったこととrails側でやったことがあり、それぞれ以下のようになります。感想はたして我々は「普通になったのか?」かはまだ良くわかりません。確かな実感としてこの仕組の上で作られた機能は作り込みの限界が高くなっていると感じます。いまの普通は昔の普通よりずっとすごい。残せるように、これからも普通のことをやっていこうと思います。最後にマネーフォワードでは、エンジニアを募集しています。ご応募お待ちしています。