大規模プロダクトWebpackやっていく気持ち@_tohashi

about me

• Takumi Ohashi• twitter: @_tohashi• GitHub: @tohashi• freee という会社でエンジニア

会計 freee

• クラウド会計ソフト• 2013/03/19 リリース• 日々機能追加や改善を続けています

昨年中頃までコーヒーバックボーンスプロケッツ

最近バベルリアクトガルプウェブパック

フロントのモダン化進行中• CoffeeScript, Backbone.js, Sprockets ->

Babel(ES2015), React.js, gulp.js, Webpack

• 新規開発やリファクタ部分をメインに段階的に移行中• 似たような話は最近ちらほら

ビルドは gulp.js & Webpackで• scss, images, template

-> gulp.js で build & watch• JavaScript(ES2015), CoffeeScript

-> Webpack で build & watch• npm script でまとめて実行

ある日の開発風景

今日も js書くぞ〜〜〜

…

暇になって遊び始める

コミットして一旦ブランチ変えるぞ〜〜〜

突然の死

最初に戻る

監視対象が多い• JavaScript: 800• CoffeeScript: 600• Sass: 200• gulp.js の performance issue は v4 で解決するという話もあるが…

jsのエントリーポイントが多い• SPA ではない• 元々 application.js 一つだけだったのをルーティングごとに依存解決して分割していった• 結果、現在の js エントリーポイント数 : 80

Webpackのモジュール解決• 最初に依存関係にあるモジュールを全部ビルドしてキャッシュ• 以降、変更のあったモジュールのみビルドし直す（インクリメンタルビルド）• 当然ファイル数に応じて時間がかかる

ファイル変更検知と最初に全モジュールのビルドをやめる

webpack-dev-server

• Webpack の成果物配信用のローカルサーバーを起動（中身は express ）• Hot Module Replacement でページをリロードせずに部分的に更新• 最初に全部ビルドするのは変わらず

lazy mode

• 変更を監視せずに、ローカルサーバーに対してリクエストがあったタイミングでビルド• Hot Module Replacement との併用はできない• assets の参照先を lazy mode で起動した

webpack-dev-server に変更

DEMO

やや改善したが…• 立ち上がりの遅さ & メモリ使用量は改善• 結局初回リクエスト時に各モジュールをビルドし直すのはそれなりに時間がかかる• 前回起動時のキャッシュを import して再利用できれば早いのでは• プラグインないので作るよ！

DEMO進捗ダメです

展望• キャッシュの件はうまくいったら公開します• gulp.js と Webpack の併用は正直しんどい• CSS なども Webpack に寄せていきたい

• CSS in JS にするかはさておき…

フロントエンド環境• 日々いろんな事例は聞くけど微妙にコンテキストやアーキテクチャが違う

• Web サイト or Web アプリ , SPA or ページ遷移 , サーバーサイドの環境、 etc…• 確立されたものはないのでアプリやチームの変化に対応していく必要がある• フロントエンド環境職人が求められる

やっていく気持ちをもってやっていきましょう

求人情報• gulpfile とか webpack.config 書くのが趣味の人• 「 ES6 で書く」と聞くと「 ES6 なんて名前の言語は存在しない（後略」と言わずにはいられない人• jQueryUI に親を殺された人

ありがとうございました