この記事はECMAScript6の事始めとして、ライブラリをES6で書いて公開するというところから始めるのがいいのではという内容です。

現在のES6 -> ES5

ECMAScript6は現在策定の最終段階で、メジャーなブラウザの最新版は多くの機能を既に実装しています。

しかし、現実には最新版以外の実行環境でも動くように書くと思うので、ES6のコードをES5に変換して利用すると思います。

今すぐ、ES6でコードを書いてES5に変換するツールは色々あります。

Compare · 6to5を見てみるとそれぞれがサポートしている機能がわかると思います。

少し注意したほうがいいのは、上記のツールは構文(classやmoduleなど)をサポートという意味が多いです(そうじゃないとシンタックスエラーになるので)。

一方、Array.fromやPromiseといったAPIは別のpolyfill(またはruntimeなどと言わわれるもの)を使いサポートしているという違いがある事には少し注意しておいたほうがいいです。

なので、こういった変換ツールを使う際は構文のサポートを求める感じで使うのがいいと思います。 逆にpolyfillで対処できる機能は別にES6で書かなくても利用することができます。

polyfillについては以下を見ていくと面白いと思います。

簡単にまとめると、ES6の構文を使うことでコードもシンプルになりますが、それを公開するためには変換ツールを使わないといけないというのが現状だと思います(一種のAltJSみたいなもの)

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

じゃあ手始めにどういう時にES6で書くのがいいかというと、ライブラリとして公開するようなコードをES6で書くのがいいと思います。

具体的な例と共にES6で書いてnpmでライブラリを公開するまでを見て行きたいと思います。

扱う題材をシンプルにするためにNode.jsのライブラリとして考えます。

以下のazu/textlint-rule-helperというものを例にして見ていきます。 (このライブラリはtextlintというツールのルールを書くのを補助するライブラリですが今回はどうでもいいです)

上記にリポジトリをみてもらうと、ES5のコードやgulp等の設定ファイルも存在しない事がわかると思います。

file tree

ライブラリの構成

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

  • src/ : ES6で書かれたコード
  • lib/ :see_no_evil: : 6to5で src/以下のコードを変換したES5のコード
    • lib/ ディレクトリは .gitignoreで無視して、リポジトリには含めない
    • 変換後のソースはGitで管理しない(そうした方がPull Request時に迷わない)
    • 逆にpackage.jsonのfilesフィールドでは "files" : ["lib"]のみとする
    • npmが軽量になるし、npmで取ってきたファイルはlib/以下のES5のコードのみにできる
    • 細かすぎて伝わらない package.json 小ネタ三選 - t-wadaのブログ
  • test/: ES6 + mocha + power-assertでテストを書く
    • azu/espower-6to5を使うことで、mocha --compilers js:espower-6to5/guess と指定するだけでテストもES6で書ける
  • README.md : ドキュメント
    • ライブラリにはドキュメントは必要。いくら良いコードでもドキュメントがないならゴミ
    • JSDocでドキュメントを書き、jsdoc-to-markdownでREADMEに追加出来るように自動化する
    • jsdoc-to-markdownを使うことで、template/のテンプレートを使ってREADMEを生成できる
    • JSDocを変更する度にREADMEを手動で変更する必要がなくなる

ざっくり見ると azu/textlint-rule-helper は上記のような構成で動いています。

tree

(OmniGraffleのアイコンにディレクトリをD&Dするとこういう図ができる - OmniGraffle Folder Trick — MacSparky)

src/

ES6で書いたコードを置く場所です。 AltJSでもsrc/にAltJSのソースを置くのと同じような話です。

lib/

JavaScriptのコードを置く場所です。 Node.jsでは一般的にlib/以下にJSのソースをおいてると思います。

ここに置かれるJSはsrc/のものをES5に変換したものが配置されます。

ES6 -> ES5の変換には6to5を使っています。 devDependenciesで入れておいて、npm run-scriptで実行するようにすればglobalに入れる必要はありません。

  ...
  "scripts": {
    "build": "6to5 src --out-dir lib  --source-maps-inline",
    "watch": "6to5 src --out-dir lib --watch --source-maps-inline",
    "test": "npm run build && mocha test/*.js"
  },
  "devDependencies": {
    "6to5": "^2.7.4",
    "mocha": "^2.1.0",
    "espower-6to5": "^1.0.3",
    "power-assert": "^0.10.0",
  }
  ...

しかし、変換したJSにPull Requestとか送られても困るのでGitリポジトリにはlib/は含めないようにします。

.gitignore に以下のように書いて、libディレクトリを無視させます。

/lib

逆に、npm publishで公開するときには、ES5に変換されたコードだけを公開したいです。 そういう時は、package.jsonの"files"フィールドに、ホワイトリストで含めたいファイル or ディレクトリを指定出来ます。

lib/だけを含めたいので以下のように書くことが出来ます。

{
  "name": "textlint-rule-helper",
  "description": "Helper for textlint rule.",
  "version": "1.1.2",
  "homepage": "https://github.com/azu/textlint-rule-helper/",
  "repository": {
    "type": "git",
    "url": "https://github.com/azu/textlint-rule-helper.git"
  },
  "main": "lib/textlint-rule-helper.js",
  "files": [
    "lib"
  ]
}

package.jsonやREADMEやLICENSE、CHANGELOG等のファイルはデフォルトで含まれるようになってるので書かなくても問題ありません。

npm info textlint-rule-helper

で直接.tgzファイルを落としてみると含まれてることが分かると思います。

ホワイトリストで指定する事でnpm packageのサイズが小さくなるというメリットもあるので、自然と取り入れやすいです。

test/

テストもES6で書き、power-assertを使いMochaでテストします。

テストファイルではlib/にある変換されたファイルを読み込みテストします。(src/ではなく、実際に配布されるファイルでテストする)

import {RuleHelper} from "../lib/textlint-rule-helper.js";
// package.json に "main": "lib/textlint-rule-helper.js", とある場合
import {RuleHelper} from "../"; // でも同じ意味になる

しかし、このテスト構成だと、6to5はES6->ES5の変換、power-assertはJS->JSの変換を行う必要があります。

つまり、6to5で変換してからそれを更にpower-assert向けに変換し直して、mochaで実行するという流れが必要になります。

gulpで表現すると以下の様な流れですね。

gulp.task('powered-test', function () {
    return gulp.src(TEST)
        .pipe(sourcemaps.init())
        .pipe(to5())
        .pipe(espower())
        .pipe(sourcemaps.write())
        .pipe(gulp.dest('./powered-test/'));
});

実際にgulpでやる場合は以下のリポジトリ等を参考にしてみるといい気がします。

自分は設定ファイルとかを別途作成するのは好きじゃないので、azu/espower-6to5というモジュールを作成しました。

azu/intelli-espower-loaderと大体同じような事をやっていて、6to5 + power-assertの変換を一緒に実行時にやってくれるhookスクリプトです。

npm install espower-6to5 -D
mocha --compilers js:espower-6to5/guess test/**/*.js

とするだけで、ES6で書かれたテストコードをpower-assertを使ってテストすることが出来ます。

power-assertを使わない場合は以下のように書くだけで問題ないので、azu/espower-6to5は不要です。

mocha --compilers js:6to5 test/**/*.js

Tips

ES6ではArrow Functionが使えるので、以下のように書くことが出来ます。

describe("#getParents()", ()=> {
   context("on Document", ()=> {
       it("should return []", () => {
           var text = "# Header";
           var parents = [];
           assert(parents.length === 0);
       });
   });
});

しかし、thisの扱いが違うのでテストケース間でthis.prop的なやり取りをしたい場合は気をつけましょう。

Document

このライブラリは小さいことを前提としてたので、 README.md にAPIの一覧をコード内のJSDocから生成して出しています。

75lb/jsdoc-to-markdownを使い、README.template.mdを用意してこのファイルからJSDocの情報を使ったREADME.mdを生成しています。

  "scripts": {
    "docs": "jsdoc2md -t template/README.template.md lib/textlint-rule-helper.js > README.md",
  },

正直この方法はかなり限定的で、色々環境で上手く働く感じではない気がしてるので、 README駆動とかソースコードとドキュメントの分離とかもっと別の方法があるかもしれません。

理想的にはd.tsかWebIDLでインターフェースを書いてドキュメント化できるといい気がしますが今のところツールがないので。

エディタ

好きなエディタをつかって下さい。

WebStorm等のJetBrains IDEのES6対応は微妙に古い所があるので、casser/intellij-es67のプラグインを一緒に入れるとES6 modulesの扱いなどが改善します。

ES6

各自調べて下さい。

構文だけに限ってみても Template Stings、Spread operator、Computed Property Names、ES6 classなど、コードがシンプルに書きやすくなる部分が多いので、小さいライブラリを書くことで慣れておくといい気がします。

特にES6 modulesはちょっと表現力が高くて、仕様のシンタックスも固まったので慣れておきましょう。

ライブラリで今までクラスっぽいものを書いて公開してるケース等はES6 classを使えば、シンプルに書けるようになるのでおすすめです。

export class RuleHelper {
  // コンストラクタ
  constructor(ruleContext) {
    this.ruleContext = ruleContext;
  }
  // 静的メソッド - RuleHelper.getHoge()
  static getHoge(){
  }
  // プロトタイプのメソッド - ruleHelper.isFuga()
  isFuga(){
  }
}

ES6の書籍

ES6の仕様についてのコミュニティ