先日、npmからconstなど一部ブラウザが対応してないコードが入ってしまってハマったが、逆にpublishする側になったら以外と「これどうしようか？」と思って調べた。

目的

npmにpublishするためのビルドがしたい
なるべく簡易に、ミニマムに。
うっかりbrowser対応されてないようなコードで利用者が不幸になるのなるべく防止したい。ぐらいな心持ち
「えっbabel-cilって同名ファイル吐き出してるだけじゃん。これ何に使うの」という疑問の解消

目的外のこと

積極的にbabelっていく話
- .babelrc次第でどんどん使えますが、そこ自体は目的にしてません。お好みで。
node.js向けオンリーのnpmパッケージの事
- 用途次第で、ブラウザが対象外なものなら、複雑化させずにそのままpublishしていいんじゃないか派です。
module 解決したり結果bundleしたりminifyしたりする話
- しません。browserify、webpack、rollupらへん使いましょう
umdなども吐く話
- しません。browserify、webpack、rollupらへん使いましょう
- なんとなく著名パッケージ眺めると良いかもしれません（後述）

方法：babel-cliを使う

babel-cliはそもそも何をしてくれるのか？

単純にbabelというコマンドで、引数として与えられたディレクトリのファイルを変換する。
単体で使った場合には、純粋にコードの静的変換だけをしている。
当然、Webpackやbrowserifyを使った時のように、requireやimport/exportの解決をしたりはしない。

% npm run build

> sample@0.0.1 build /path/to/project
> babel src --out-dir lib

src/index.js -> lib/index.js
src/some-module.js -> lib/some-module.js

通常のWeb開発だとbrowserifyやwebpackと組み合わせてbundleするので、あんまり使い所ないのでは？と思っていたが、npmにpublishするときは逆にbundleせずにバラバラに変換するだけ、というのが都合が良い。

Setup

babel-cliとbabel-preset-es2015入れておく

$ npm i -D babel-cli babel-preset-es2015

お好みでrimraf。ビルド前にディレクトリクリーンしておくのに便利

$ npm i -D rimraf

ディレクトリ構成

だいたいこんな感じ。

├── src // ビルド前のファイル
│   ├── some-module.js
│   └── index.js
├── test // テスト
├── lib // ビルド後ファイル。
│   ├── some-module.js
│   └── index.js
├── README.md
└── package.json

package.json

babel-cliをディレクトリごとlib/に出力して、公開対象をlib/にする。

package.jsonはこんな感じになる。

package.json

{
   :
  "main": "lib/index.js", // 重要
  "scripts": {
    "prebuild": "rimraf lib",
    "build": "babel src --out-dir lib", // 重要
    "preversion": "npm run build",
     :
     :
  },
  "files": [ 
    "lib" // 重要
  ],
  "devDependencies": {
     :
    "babel-cli": "^6.14.0",
    "babel-preset-es2015": "^6.14.0",
    "rimraf": "^2.5.4"
     :
  }
}

mainフィールドはlib/main
同様、fileには["lib"]と指定。
npm run buildでbabel src --out-dir lib で src -> lib と吐き出す。
他のscriptsは単なる便利化。
- pre,postをつけておけば自動的にビルド実行してくれる。npm version、npm publish時に漏れないようにbuildしておく。
- prebuildでrimrafを使ってディレクトリクリーンしておく。

もしsrcでimport/exportを利用して、Webpack 2系やrollupのtree shakingを使いたいと思っているのであれば、下記を記載しておいても良い。

package.json

{
    :
  "main": "lib/index.js", 
  "module": "src/index.js", // for webpack 2
  "jsnext:main": "src/index.js", // for rollup
    :
}

Tree shakingについて詳しく知りたい場合は下記あたりが詳しめなので参照のこと。

.gitignore

生成ターゲットは基本ignoreしといていいはず。

.gitignore

lib/

.babelrc

あんまり特殊な事は無いが、最低限これ入れておけば大丈夫だろう、ぐらいなチョイスとしてpreset-es2015を入れた。¹

looseオプションをtrueにすべきかなど悩ましいが、reduxあたりを参考にtrueにした。

.babelrc

{
  "presets": [
    ["es2015", { "loose": true }]
  ]
}

欄外メモ：.babelrcのenvと`BABEL_ENV`

reduxのbabelrcを覗くと、envというオプションが設定されている。

.babelrc

{
  "plugins": [
    :
    :
  ],
  "env": {
    "commonjs": {
      "plugins": [
        ["transform-es2015-modules-commonjs", { "loose": true }]
      ]
    }
  }
}

これは特定の場合だけに特定のpresetオプションを効かせたい場合に使えるらしい。

$ BABEL_ENV=commonjs babel src --out-dir lib

とすると、env.commonjsに記載したpresetを追加で効かせる、という効果。
普通そんなに使わなそうだなと思ったが、bablejs.ioによると、このような特定bundle向けの他に、「developmentの時だけ特定のpluginを効かせたい」というようなことも利用想定としているようだ。

まとめ

参考にした package.json

npm向けはbabel-cliにしてるパッケージ

今回取った手法 + webpack的な感じ。
webpack併用しているのが多いが、npm用というよりumd配布など向けっぽい

Grunt使ってビルド

react
- gruntからbrowserifyっぽい
axios
- gruntからwebpackっぽい

rollup派

思ったよりパラパラ見てたらrollup派がいた。

雑感

babel-cli今までデバッグ用ぐらいにしか使えない子だと思っててごめんなさい
webpackとかbrowserifyナシで全然いけるのはだいぶ楽
umdとか結構配布しているけど、需要どれだけあるんだろう？と思った。

preset-latestでも良いかなとも思っているが、まだちゃんと調べられてないので保留した。 ↩