ライブラリをES6で書く所から始めよう

目的

6to5の紹介
Node.jsライブラリをES6で書いて公開するのは無理なくて良い
逆にfilesなどnpm公開のベストな手法を選択がセットとなる
現在のES6変換器に求めるべきは構文であって機能じゃない(機能はpolyfillが持つ)
- letとか変換でどうやっても結果が見えてるので無理に使う必要はないと思う。
- Template StingsとかSpread operatorとかCompute property nameとかclassはコード自体がシンプルになるので使っていくといい
  今ES6で書く手段

今ES6でコードを書く方法は色々ある。

6to5
Traceur
TypeScript

Compare · 6to5

ライブラリをES6でnpmで公開してみよう

メインのコードは大きくなるからコンパイルしたくない人も多いはず。でも、ライブラリなら結構気軽にES6で書いて公開することができる。

例: azu/textlint-rule-helper

上記にリポジトリをみてもらうと、ES5のコードやgulp等の設定ファイルも存在しない事がわかる。(ブラウザ向けのコードだと必要になる可能性が高いけど、Node.js向けならなくてもいけるという事を示す)

ライブラリの構成は以下のようになっている

src/ : ES6で書かれたコード
lib/ : 6to5でsrc/以下のコードを変換したES5のコード
- lib/: このディレクトリは.gitignoreでリポジトリには含めない
- 変換後のソースは見えないほうがリポジトリがキレイ(Pull Requestしやすい)
- 逆にpackage.jsonのfilesフィールドでは "files" : ["lib"]のみとする
- npmが軽量になるし、npmで使う時はES5のコードのみにできる
- 細かすぎて伝わらない package.json 小ネタ三選 - t-wadaのブログ
test/: mocha + power-assertでテストを書く
- azu/espower-6to5を使うことで、--compilers js:espower-6to5/guess と指定するだけでオンザフライの変換ができ、テストもES6で書ける
npm run-script: 6to5を使いbuild,watch,test を加える
ドキュメント: APIにはドキュメントは必要。いくら良いコードでもドキュメントがないならゴミ
- JSDocでドキュメントを書き、jsdoc-to-markdownでREADMEに追加出来るように自動化する
- jsdoc-to-markdownを使うことで、README自体がテンプレートとなってJSDocを変更する度にREADMEをいじる必要がなくなる
- npm run docsでREADMEが更新できる
- JSDocのHTMLって誰も見ないと思ってる。jsdoc-to-markdownも何か微妙な感じがあるけど…
- 逆の考えでREADME駆動的にドキュメントをコードに落とすという考え方もある
- 理想的にはd.tsかWebIDLでインターフェースを書いてドキュメント化できるといいけど、今のところツールがない。