importの解決でBrowserifyからのBabelify
ECMAScript6でクライアント側を書いてますが、極小のHello Worldレベルから一歩進むだけで壁が。JavaScriptの発展の歴史の中で大きなアプリケーションを作るためのパッケージ参照機構が様々用意されてたみたいですが、そこにまた大きな曲がり角が出てきちゃってた。
- 原始時代より長らくHTML上でscriptタグのsrc属性にファイル名を指定することで読み込むという参照方法のみだった。
- サーバ側でもJavaScript使おうよとNetscapeを始め何度か繰り返されては散り、しばらく忘れ去られていた太古の試みは、Node.jsの登場でルネッサンス。
- Node.jsがプラットフォームとして実装したrequireでnpm管理されたパッケージ構成を参照させたのを模して、独自にライブラリレベルでrequireをクライアント側へ導入する文化が花開く
- 産業革命。ES6でimport/exportの言語表記が標準化される。Node.jsもio.jsとの分離と再統合を経てES6に対応。しかし環境として世に数多あるブラウザがES6対応版に置き換わってくるのはこれから
今はimport書いてもそのままでは動かない。Babelではimportをrequireに書き換えるからrequireをbabel/registerなどでライブラリとして手当しないといけない。そんな中、そもそもファイルが分割されているから参照機構が必要なんじゃないかと動乱の中でちゃぶ台ひっくり返したのがBrowserifyでした（この前知ったばかりなのに適当な説明しちゃったな）。
Transpilerとしてrequireが書いてあるコードの参照を辿ってライブラリを探し、見つけたもの皆を一つのファイルに合体させちゃうという。イイね！さらにTranspile時にBabelしちゃいましょうというのがBrowserifyのプラグインであるBabelify。合わせ技でimport/exportを解決。
Githubサイトの説明に書いてある通り、ターミナルでコマンド一発です。
$ browserify App.jsx -o public/js/bundle.js -t babelify
あとはHTMLのsrcで参照するタイプのscriptタグを全部削って、生成物を参照するscriptタグだけに変える。その前にライブラリはできる限りnpm管理でnode_module配下にしとくこと。
<script src="js/bundle.js"></script>
こうなってくると、WebStormのファイル監視にBabelを設定して自動Transpileしていたのを外して、動作確認が必要な時にBrowserifyを叩くってことになりますね。複数ページになって複数のブロック構造になってくるとまたどうしたもんかねとかあるけど、この辺は愚直にやっても数はブロック数に限定されてるので手間じゃなくいいんだと思う。
