プロジェクトの中のBabel
前章で、実際のプロジェクトでは babel コマンドを使わないと書きました。 それではどのような呼び出し方をされるのでしょうか。 実は、Babelを使う上で一番難しく、引っかかる部分はここなのではないかと思います。
プロジェクトの中では、npm でインストールできる様々なJavaScriptソフトウェアが使われます。 例えば、ユニットテストをする mocha や、みんな大好き webpack などがあります。 これらのソフトウェアは、本来は古いJavaScriptしか理解できないはずですが、 多くの場合内部でBabelを使う方法をそれぞれ独立して持っています。
とてもめんどくさい。
例: mocha
mochaはユニットテストのフレームワークです。 もちろんBabelを使わなければ、 ソースコードにもテストコードにも最新のECMAScriptは使えません。
mochaの場合、このようなオプションを渡すと、 ソースコードもテストコードもどちらもBabelでトランスパイルできます。
$ mocha --require babel-register --compilers js:babel-register test/*.test.js意味のわからないオプションですね。 babel-cli は不要で、 babel-register だけインストールされていれば動きます。
例: webpack
webpackは、スクリプトだけでなくCSSや画像までをも、Web配信に適した形にまとめるソフトウェアです。 webpackは様々なフォーマットのファイルをJavaScriptで読み込める形にするために、loader という仕組みを使います。
例えば、 json-loader は、JSONファイルを require すると、ただのJSONではなく
module.exports = ファイルをJSONとして解釈したデータという形に変換されたファイルを require します。
Babelを使いたいのなら、 babel-loader を設定すれば簡単にトランスパイルできます。 babel-cli は必要ありません。
$ npm install -D webpack babel-loader json-loaderwebpack.config.js はこのようになります
例: 手動
これらのオプションを使わない、またはこういうオプションがない場合、 手動でトランスパイルする必要があります。 例えばmochaなら、 src/* を lib/*, src.test/* を test/* にトランスパイルし、
を実行するとおそらく正しくテストができるはずです。
ただこの場合、失敗したテストのスタックトレースなどは、 トランスパイル後のファイルに準じるので、非常に不便を感じることになるでしょう。
まとめ
それぞれのソフトウェアごとに、正しいBabelの設定方法を把握しないといけません。 かなりダルいです。 全部違います。 非常にダルいです。
おまけ: npmにパッケージを公開する
npmにパッケージを公開する場合、そのコードは素のNode.jsで実行できないといけません。 よって最新のECMAScriptで書かれたソースコードは、公開前にトランスパイルしなければなりません。
多くの場合、 src/ のECMAScriptコードを lib/ に出力するようにしています。 package.json に
と書いておけば、publish時に自動でトランスパイルしてくれるようになります。
gitリポジトリには src/ のみをコミットし、npmには lib/ のみをpublishします。 これには .gitignore と .npmignore を利用します。
.gitignore には
を
.npmignore には
を含めるようにします。 .npmignore が無いと .gitignore が代わりに使われてしまうので、 公開されたパッケージになぜか lib/ が存在しないという気づきにくい罠にハマってしまいます。
Last updated