1. モジュールバンドラーとは
2. どんな時に使いたい？
3. 「requireを使える」ということ
4. 様々なモジュールバンドラー
5. browserify を使ってみよう
6. browserify + Grunt で自動コンパイルする
7. まとめ

モジュールバンドラーとは

モジュールバンドラー（module bundler）は、文字通りモジュールをひとまとめにする（bundle）ツールです。 あまり用語として聞き慣れませんが、モジュールバンドラーの代表格のひとつである webpack でも使用されている言葉です。 ひらたく言うと、JavaScriptの依存関係を解決し、それらをインクルードしたひとつのファイルにまとめてくれます。

上の図のように、 require で表現された依存関係を解決してゆき、 コンパイルする際にそれらを全て内包したファイルを作ってくれるのが一般的なモジュールバンドラーの振る舞いです。 require はもともとサーバーサイドJavaScript用に考えられた仕様なので、基本的にブラウザ上では動きません。 それをブラウザ上でも利用可能にするというのが主な目的です。

どんな時に使いたい？

1. JavaScriptファイルを連結したい

旧来JSファイルを連結する際には、まとめたいファイルを指定してシンプルにファイルを繋げていましたが、 この方法には「連結するファイルリストを管理しなければならない」という煩わしさがあります。

一方でモジュールバンドラーの場合はコード内の require を辿って必要なファイルだけを梱包してくれるので、 ファイルリストの管理から解放され、モジュールの取捨選択も一行の追加・削除だけで解決できます。

2. JavaScriptでモジュールのインポートをしたい

他言語で import や require を使っている方は「モジュールのインポートができる」事の素晴らしさも十分にご承知だと思います。 要するに、一行加えるだけで別ファイルに記述された機能がそのファイル内で利用できる様になるのです。

また同時に、コードを見直す際などに依存関係が一目瞭然になるのも大きな利点です。 Webアプリケーションの開発ではJavaScriptファイルが肥大化・複雑化するので、なんとしても欲しい仕組みですね。

3. パッケージマネージャーを npm で一本化したい

bower 等のパッケージマネージャーを利用されている方は一度はその管理に頭を悩ませるでしょう。 bower はそれ自身を npm でインストールして、.bowerrc と bower.json で設定を行って管理するのですが、 「どうせ npm で package.json があるんだからそっちで一本化したい」となるわけですね。

モジュールバンドラーは基本的に node_modules ディレクトリからモジュールを探してインポートするので、 全て npm だけで解決する事ができ、管理が大変楽になります。

4. node.js のモジュールをブラウザ上で使いたい

node.js 向けに作られたモジュールも（一部をのぞいて）インポート可能です。

まとめると

プロジェクトの規模が大きければ大きいほど、より効力を発揮すると言えそうです。

「requireを使える」ということ

node.js に明るくない方の為に簡単に補足をしておくと、 require / exports というのは node.js で使われているモジュールの読み込みの仕組みで、CommonJSなどと呼ばれていたりします。 例えばみんなだいすきjQueryを読み込みたい場合は、まず npm で jquery をインストールします。

$ npm install jquery@1 --save

そしてJavaScript側で require します。

var $ = require("jquery");

これだけで、そのファイル内ではいつも通りに $ でjQueryを参照する事ができます。簡単ですね。

また、「そのファイル内では」という所がポイントで、上の例の記述はグローバルな空間を汚染しません。 つまり、そのファイルのコンテキスト外で jQuery を利用しようとしても、参照出来ないという事です。

ローカルモジュールを組み込む

npm で導入したのではない、自前のモジュールを読み込みたい場合は、そのファイルまでの相対パスで指定します。

var utils = require("./modules/utils");

ここで注意したいのは、相対パスを “./” からはじめている部分です。 これが “modules/utils” だとモジュールの名前だと判断され、 “modules/utils” という名前のモジュールを node_modules から探そうとしてしまいます。

require できるローカルモジュールを作る

モジュールの宣言は exports あるいは module.exports に代入して行います。 まずは exports から使ってみましょう。

// modules/utils.js
exports.foo = function(){ return "foo"; };
exports.bar = function(){ return "bar"; };

このように書く事で、require の返り値がプロパティに foo と bar を備えたオブジェクトになります。 要するに、モジュール内で宣言されている exports オブジェクトを返しているわけですね。

var utils = require("./modules/utils");
utils.foo(); // => "foo"

対して module.exports は、返り値そのものを書き換えたい場合、たとえばオブジェクトではなく関数等にしたい時に有効です。 クラスを返したいケースなどで使えますね。

// modules/foo.js
var Foo = function(){ ... };
module.exports = Foo;

このようにすると、返り値は Foo 関数そのものとなります。

var Foo = require("./modules/foo");
var foo = new Foo();

様々なモジュールバンドラー

browserify

Browserify – http://browserify.org/
Browserify lets you require(‘modules’) in the browser by bundling up all of your dependencies.

• 単機能な方向性で、シンプルで簡単
• Gulpとの相性はイマイチです

webpack

webpack – https://webpack.github.io/
webpack, the flexible module bundler

• JSのバンドルに留まらず多機能ですが、設定が少々ややこしい
• Gruntとの相性はイマイチです
• AMD仕様でのモジュール定義も可能
• browserifyと比較して速度でアドバンテージがある様です

RequireJS という物もありましたが、モジュールの定義がCommonJSではなく本記事に沿わないので割愛します。 browserifyは単機能でシンプル、webpackは多機能という印象です。

browserify を使ってみよう

シンプルな browserify を実際に使ってみましょう。 前提条件として、node.js がインストールされている必要があります。

1. インストール

ターミナル等で browserify をインストールします。環境によっては sudo を頭に付ける必要があります。

$ npm install -g browserify

インストールが完了すれば browserify コマンドが使用可能になります。

$ browserify --help
Usage: browserify [entry files] {OPTIONS}

2. 実行する

適当なJSファイルを用意して、browserify コマンドでコンパイルしてみましょう。

$ browserify test.js -o bundle.js

こちらが基本形です。上のコマンドを実行すると、test.js をコンパイルした結果が bundle.js として保存されます。

browserify + Grunt で自動コンパイルする

browserify コマンドを毎度実行するのは面倒なので、 タスクランナー（Grunt）でファイルの更新を検知して自動的にコンパイルする環境をつくります。 （前述にもありますが、Gulp + browserify は少々手間がかかり説明に不向きなので、ここでは Grunt で説明します）

ファイル構成例

/
├ html/
│ └ assets/
│      └ js/
│           ├ src/
│           │ ├ modules/
│           │ │ ├ mymodule-01.js
│           │ │ └ mymodule-02.js
│           │ └ main.js ... エントリーファイル
│           └ main.js ... コンパイル先のJSファイル
├ node_modules/
└ Gruntfile.js

設定

まず必要なモジュールをインストールします。

$ npm install grunt grunt-browserify grunt-contrib-watch --save-dev

Gruntfile.js を用意します。タスクの設定は下記のような感じにしてみます。

grunt.initConfig({

    browserify: {
        dev: {
            options: {
                borwserifyOptions: {
                    debug: true
                }
            },
            files: [
                {
                    expand: true,
                    cwd: "html/assets/js/src",
                    src: "*.js",
                    dest: "html/assets/js"
                }
            ]
        }
    },

    watch: {
        js: {
            files: ["html/assets/js/src/**/*.js"],
            tasks: ["browserify:dev"]
        }
    }

});

• html/assets/js/src/*.js をエントリーファイルとして、同名ファイルを html/assets/js/ に書き出します
• html/assets/js/src/**/*.js が変更されると、browserify タスクが走ってコンパイルを行います
• browserify に渡すオプションは、browserifyOptions に記述します。 debug を true にするとソースマップを生成する様になります。

準備が整ったら watch してみましょう。

$ grunt watch

無事動きましたか？

まとめ

モジュールバンドラーは昨年（2015年）あたりから流行りだして、 使ってみたところあまりにも効率が良く、今ではもう手放せない存在になりました。 CSSプリプロセッサ、タスクランナーと並んで、近年の素晴らしすぎる発明の一つですね。

新しくなった Google スプレッドシート

今までは個人設定をいじる事で旧バージョンのスプレッドシートを使い続ける事ができたのですが、 先日からそのオプションが設定画面から消えていて、特別な方法をとらないと旧バージョンのスプレッドシートを新規作成出来なくなりました。 （すでに作成したスプレッドシートは変更されない様です）

刷新された Google スプレッドシートにどのような素晴らしい機能が追加されたかは未だあまり把握していませんが、 現状で確かな事は、旧バージョンで使えたRSSやJSONでの公開APIが実装されていないという事です。 今後実装されるかどうかはわかりません。

以前書いたGhostsheetはそれらの公開APIを利用した物だったので、新しいスプレッドシートでは使用する事ができません。

2014/11/20 追記

現在ではAPIが整備された様で、新しいスプレッドシートでも旧Ghostsheetが正常に動作する事を確認しました。
Googleスプレッドシートを簡易DBとして利用する -　PHP+Ajax編

Ghostsheet も新しくしました

とはいえ、pubhtml（Webページの公開）APIは利用可能なので、それをスクレイピングしてデータ化する物を新たに書きました。 全く別物になったのでリポジトリも改めています。

• mach3/ghostsheet2 @ GitHub

簡単な使い方

以前と同様に、スプレッドシートを作成して「Webに公開」します。

一行目のヘッダ部分でデータの型を指定する事が出来ます。 上記にある integer、bool の他に、float、json が利用出来ます。 省略時は string になります。

そしてスプレッドシートのキーをメモしておきます。スプレッドシートのキーはURLの下記太文字の箇所になります。

https://docs.google.com/spreadsheets/d/00X_xxxXX_0xXxxXx00XXXxx-xxXXxX0-XxXxXx0XxxX/edit#gid=0

このキーをそのまま引数にしてメソッドの呼び出しをします。

<?php

require "the/path/to/ghostsheet/phplib/Ghostsheet.php";

$gs = new Ghostsheet();
$gs->config("cache_dir", "./cache");
$data = $gs->load("00X_xxxXX_0xXxxXx00XXXxx-xxXXxX0-XxXxXx0XxxX");
var_dump($data);

結果は連想配列で返され、”sheets” の中に各シートのデータが格納されるようになっています。

array(3) {
  ["title"]=>
  string(4) "My Spreadsheet"
  ["key"]=>
  string(44) "00X_xxxXX_0xXxxXx00XXXxx-xxXXxX0-XxXxXx0XxxX"
  ["sheets"]=>
  array(2) { ... }
}

旧版との大きな違い

旧版ではスプレッドシートに含まれるシート名で引くためには複数回リクエストしなければなりませんでしたが、 pubhtmlでは全てのシートがひとつのWebページで公開される為、一回のリクエストで済みます。 あまり大量のデータになると辛そうですが、そういった大きなデータでは利用すべきではないと思うので、 結果的には効率が良くなったと言えそうです。

メソッドの使い分け

Ghostsheet にはデータを取得する為に4つのメソッドがあります。

• load
  • キャッシュファイルが期限切れでなければそれを使用
  • そうでなければリモートから最新のデータを取得し、キャッシュファイルを更新
• cache
  • キャッシュの生死に関わらずキャッシュのデータを返す
• fetch
  • キャッシュの生死に関わらずリモートからデータを取得
  • キャッシュの更新は行わない
• update
  • キャッシュの生死に関わらずリモートからデータを取得
  • キャッシュの更新を行う

一見すると load で良さそうですが、その場合、キャッシュの期限が切れるたびにレスポンスが遅くなるタイミングが出てきてしまいます。 対策としてはデータの取得は常にキャッシュから行い、非同期で load を呼び出すのがレスポンスに優しそうです。

（おまけ） Gruntタスク

おまけ機能としてGruntタスクをつけておきました。 スプレッドシートのデータを引っ張ってJSONファイルとしてローカルに保存するだけの簡単な物です。 シートのデータを元に静的サイトをジェネレートしたい場合などに使えたり、使えなかったり。

grunt.initConfig({
    ghostsheet: {
        dev: {
            files: {
                "./data/mydata.json": "00X_xxxXX_0xXxxXx00XXXxx-xxXXxX0-XxXxXx0XxxX"
            }
        }
    }
});

grunt.loadNpmTasks("ghostsheet2");

まとめ

わりと力技なパースなので、できれば用意されたAPIを使いたい気持ちもありますが…

ちなみに一応旧版でも新規作成する方法は残されていて、下記指定のURLにアクセスするだけで可能です。 旧版のデータが残されている以上、当面は使えそうです。

• https://g.co/oldsheets

cf) 新しい Google スプレッドシートについて – ドキュメント エディタ ヘルプ

grunt-mdeb

mach3/grunt-mdeb @ GitHub
Grunt task to publish markdown docs as EPUB 3.0 book.

Markdown書類とJSONの設定ファイルからEPUBデータを作成します。 ナビゲーションドキュメント（論理目次＋視覚目次）はMarkdownを元に出力されるXHTMLから抽出されて自動的に生成されます。 名前の「mdeb」は「Markdown to eBook」の略です。

動作環境

タスクの中でシェルコマンドを叩いている箇所があるので、 bash等が動く環境でないと動作しません。 Mac OSX や Linux なら問題ありませんが、 Windowsの場合は Git CUI（MinGW）や cygwin 環境で使用する必要があります。 Git CUI は msysgit で Git 環境を導入していれば同梱されているのでお勧めです。

• Git for Windows
• MinGW | Minimalist GNU for Windows（Git CUIの中身です）
• Cygwin

デモ兼ドキュメント

ドキュメントは grunt-mdeb のリポジトリの「demo」の中に document.epub として保存されています。 これは実際に mdeb タスクで生成された EPUB データです。 変換される前の Markdown は demo/src に、EPUBデータにコンパイルされる前の XHTML データは demo/dest/tmp に格納されています。

• demo/src （Markdownデータ）
• demo/dest/tmp （XHTMLデータ）

基本的な使い方

1. インストール

npm でタスクをインストールします。

$ npm install grunt-mdeb

2. タスクの設定

Gruntfile.js で “grunt-mdeb” を読み込み、”mdeb” タスクを設定します。

grunt.loadNpmTasks("grunt-mdeb");

grunt.initConfig({
    mdeb: {
        dist: {
            options: {},
            src: "src",
            dest: "dest"
        }
    }
});

src と dest は必須項目で、それぞれ元データと出力データの格納ディレクトリを指定します。 options は任意でオプションを設定してください。

3. データ構成

src ディレクトリの中に元データを格納していきますが、次のような構成にします。 （各ディレクトリの名前は先述のオプションで変更する事ができます）

src/
├ assets/
├ data/
│ ├ cover.md
│ ├ 01.md
│ ├ 02.md
│ └ ...
└ publish.json

data ディレクトリにはコンテンツの元になる Markdown 書類を格納します。 assets ディレクトリにはスタイルシートや画像などの依存ファイルを格納します。 assets ディレクトリの中身は全て複製されて EPUB データに同梱されます。

4. publish.json

publish.json には、タイトルや著者名をはじめ、EPUBデータを構成する為の情報を全て記述します。

{
    "meta": {
        "name": "document",
        "title": "My First Book",
        "author": "mach3",
        ...
    },
    "assets": {
        "coverImage": "assets/img/cover.jpg",
        "commonStyle": "assets/css/common.css",
        ...
    },
    "items": [
        "data/cover.md",
        "data/01.md",
        "data/02.md"
        ...
    ]
}

中のデータは３つのセクションにわかれています。

• meta
  
  書籍の基本的な情報を格納する
• assets
  
  画像やスタイルシート等の情報を格納する
• items
  
  コンテンツドキュメントの元となる Markdown ドキュメントを列挙する

items の一番最初のドキュメントは表紙ページとして扱われる点にご注意ください。 項目のさらなる詳細やサンプルは ドキュメント に記してあります。

5. コンパイルする

mdeb タスクを実行して EPUB ファイルを生成します。

$ grunt mdeb

コンパイルに成功すると、dest ディレクトリの中に生成した EPUB データと、EPUB に固める直前のデータが格納されています。

dest/
├ tmp/
│ ├ OEBPS/
│ ├ META-INF/
│ └ mimetype
└ document.epub

注意点

• 
  

  中のシェルスクリプトには rm -r なども含まれているので、使用にはご注意ください。 コンパイルを開始する前に dest ディレクトリ内の *.epub ファイルと temp ディレクトリの中全てを削除してクリーンな状態にする様になっています。

  
  
• 
  

  一応バリデーションは通るように書かれていますが、あまり盲信せずに一応確認するようにしましょう。 オプション で、 コンパイル完了時に epubcheck を実行する事も出来るようになっています。 （別途 epubcheck のインストールが必要です）

  
  
• 
  

  grunt-mdeb を使用して被ったいかなる損害についても、対応はいたしかねます。

  
  

まとめ

私は物を書くときにいつも Markdown だったので、 そのまま EPUB に出来たら楽だろうな、と思って作ってみたパッケージです。 ブログを Markdown で書かれている方も多いと思うので、 何かの役に立つことがあれば。

追記

2014/02/13

サンプルコードの initConfig の中身が間違っていたので修正