Less/Sass/Stylus をGruntでコンパイルする

ではさっそく、GruntでCSSプリコンパイラを扱うタスクを紹介します。

• grunt-contrib-less – LessをCSSにコンパイルします
• grunt-contrib-sass – SassをCSSにコンパイルします
• grunt-contrib-stylus – StylusをCSSにコンパイルします

指定できるオプションは異なりますが、設定の仕方に差はありません。

違いを挙げるならば、Less/StylusはJavaScriptで書かれているのでnode.js上で動作させられますが、 RubyベースのSassは外部のsassコマンドを呼び出す仕組みになっており、別途インストールが必要です。 結果、Gruntとより相性が良いのはLess/Stylusであると言えますね。

ここでは、私の好きなLessを例にあげてみます。

Lessをコンパイルする（grunt-contrib-less）

基本設定

まず “grunt-contrib-less” をインストールしておきます。

$ npm install grunt-contrib-less

Gruntfile.js の内容は、例えば次のようになります。

module.exports = function(grunt){

    // grunt-contrib-less タスクの読み込み
    grunt.loadNpmTasks("grunt-contrib-less");

    grunt.initConfig({
        less : {
            // 作業のラベルは"dist"にしてみます
            dist : {
                // オプションの指定
                options : {
                    compress : true
                },
                // コンパイルするファイルの指定
                files : {
                    "./assets/css/style.css" : "./assets/less/style.less"
                }
            }
        }
    });
};

※ 基本的なタスクの書き方については 前編 にて

“options”セクションでオプションの設定を行い、 “files”セクションで出力するファイルの指定を行います。

“files”のキー（左辺）には出力先のCSSファイル、値（右辺）には元となるLessファイルへのパスを指定してください。 上の例では、 “./assets/less/style.less” がコンパイルされた結果が、”./assets/css/style.css” に保存されます。

実行

$ grunt less:dist

オプション

多く使われるであろうオプションは次の物でしょう。

• compress : Boolean (false) – 空白などを除去して圧縮します
• yuicompress : Boolean (false) – cssmin.js（YUICompressorのJS版）で圧縮します

その他のオプションについては grunt-contrib-lessのREADME を参照してください。

ファイルの更新を検知してコンパイルする（grunt-contrib-watch）

基本設定

多くのコンパイラにも実装されているファイル監視機能ですが、 Gruntでも grunt-contrib-watch というプラグインとして提供されています。

npm install grunt-contrib-watch

先ほどのLessのタスクを、ファイルを監視して実行してみます。

module.exports = function(grunt){
    grunt.loadNpmTasks("grunt-contrib-less");
    grunt.loadNpmTasks("grunt-contrib-watch");

    grunt.initConfig({
        less : {
            dist : { ... }
        },
        watch : {
            // ラベルは"less"にしてみます
            less : {
                // "files"セクションで監視するファイルの条件を指定
                files : [
                    "./assets/less/*.less"
                ],
                // "tasks"セクションで実行するタスクを指定
                tasks : [
                    "less:dist"
                ]
            }
        }
    });
};

“files”セクションで監視するファイルの条件を設定します。 そして“tasks”セクションで、“files”のファイルが更新された場合に実行するタスクを設定します。

“files”の値には、直接ファイル名を指定する他にパターンマッチングを使用する事ができ、特定ファイルの除外などの細かい設定が可能です。 詳細は公式ドキュメントにあるのでご参照ください。

cf) Globbing patterns | Configuring tasks – Grunt: The JavaScript Task Runner

実行

監視を開始するとターミナルは待機状態になります。

$ grunt watch:less
Running "watch:less" task
Waiting...

“./assets/less/” にあるLessファイルを更新すると、自動的に “less:dist” タスクを実行する様になります。

livereload もある？

私は使ったことがありませんが、livereload（ファイル更新を検知してブラウザをリロードする）を実現するプラグインもあるようです。

• gruntjs/grunt-contrib-livereload · GitHub

ここでは説明を省きますが、このプラグインは上で挙げた “grunt-contrib-watch” ではなく “grunt-regarde” の使用が推奨されるようです。

Note that grunt-contrib-livereload is designed to use grunt-regarde instead grunt-contrib-watch (mainly due to shortcomings in the watch task which doesn’t give access to changed files because it spawns tasks in subprocesses.)

GUIコンパイラでいいんじゃないの？

非常にもっともなご意見です。

本記事で挙げたCSSプリコンパイラの事例に限って言えば、 Compass、CodeKitやLess.app等、優秀なGUIコンパイラが数多くリリースされているので、 「黒い画面」が苦手な方は無理して導入する事もないと思います。

ただ、GUIコンパイラに対するGruntの優位点を挙げるとすれば、 環境を跨いでの設定の共有が極めて容易な点かな、と思っています。 nodeが動く環境ならばOS問わずどこでも同じ設定ファイルで、コマンド一発で同じ事が出来るわけです。

前編で触れたGruntの魅力に興味を持たれたならば、 これを機に「黒い画面」とのお付き合いを始めてみても良いのではないでしょうか。

まとめ

そんなわけで、最近ではGitとGruntとBowerのセットで制作を進めています。

これらの優秀なソフトウェアの開発者には足をむけて寝られませんが、 オープンソース故に多方面にいらっしゃるわけで、逆立ちして寝るしかなさそうです。

1. Gruntってなに
2. Gruntを導入する
3. 使ってみよう
4. どんなタスクがあるの？
5. その他Gruntの魅力
6. まとめ

Grunt ってなに

• GRUNT: The JavaScript Task Runner

Gruntはnode.jsベースで作られたタスクベースのコマンドラインビルドツールです。

ビルドツールってなに

ビルドは、ソースファイル群を元にして、実行出来る成果物を生成するプロセスの事を指します。

cf) ビルド (ソフトウェア) – Wikipedia

鍋に鶏と野菜とコンソメを入れて煮込んだらポトフが出来るとして、 鍋の役割を担ってくれるのがビルドツールです。（そんな認識であっているかな？） レシピを設定しておくことが出来るので、いつでもすぐに美味しいポトフがお楽しみ頂けます。

具体的には、Web制作では主にJavaScriptファイルを結合・圧縮したり、 Less/Sass/Stylus等のCSSプリコンパイラの結果を生成したり、 画像の最適化などを行い、最終的に動作するWebページにしていきます。

Gruntを導入する

インストール

まずはGruntを導入してみます。node.jsベースなのでまず node.jsをインストールし、

$ npm install -g grunt-cli

等とします。環境によってはsudo等が必要です。

grunt-cli はローカルにインストールされたgruntを呼び出すだけの係の人なので、 別途gruntも入れておく必要があります。プロジェクトルートか、あるいはその親ディレクトリにインストールしておきましょう。

$ npm install grunt

使ってみよう

Gruntfile.js

プロジェクトディレクトリに Gruntfile.js ファイルを用意して設定を記述し、 そのディレクトリで grunt コマンドを実行するとビルドが始まります。

Gruntfile.js の中身は、例えば次のようになります。

module.exports = function(grunt){

    // `loadnpmTasks`で使用したいタスクを読み込んでおく
    grunt.loadNpmTasks("grunt-contrib-uglify");

    // `initConfig` で基本設定
    grunt.initConfig({
        uglify : {
            dist : {
                src : ["assets/js/script.js"],
                dest : "assets/js/script.min.js"
            }
        }
    });

    // `registerTask` でタスクに名前をつける
    // "default" でデフォルトのタスクを設定
    grunt.registerTask("default", ["uglify"]);

};

タスクについて

Gruntに命令する処理を「タスク」と呼びます。

上の例では”uglify”というタスクに、”dist”という作業を任せています。 “uglify”はuglify.js を使用してJavaScriptの圧縮を行なってくれるタスクで、 “src” にあるファイルリストをひとまとめにして圧縮した結果を “dest” のファイルに保存します。

タスクははじめから入ってるわけではないので、 使いたい物を都度インストールしましょう。

$ npm install grunt-contrib-uglify

ビルドの実行

上の例ではデフォルトのタスクにuglifyが設定されているので、引数なしで

$ grunt

とすればタスクが実行され、assets/js/script.js を圧縮した結果が assets/js/script.min.js として保存されます。

タスクを指定して実行したい場合は、引数にタスクの名前を渡します。

$ grunt uglify # <= uglifyタスクを実行
$ grunt uglify:dist # <= minタスクのdistという名前の作業を実行

どんなタスクがあるの？

以下が代表的だと思しきプラグインです。 （”contrib” とついている物は公式のものです。） 使いたい物を npm install でインストールし、 loadNpmTasks で読み込んで使用しましょう。

• grunt-contrib-concat – ファイルを結合します
• grunt-contrib-uglify – JavaScriptファイルを圧縮します
• grunt-contrib-cssmin – CSSファイルを圧縮します
• grunt-contrib-watch – ファイルの更新を監視して任意のタスクを実行します
• grunt-contrib-copy – ファイルやディレクトリをコピーします
• grunt-contrib-clean – ファイルやディレクトリを削除します

具体的な設定例等は、各リポジトリのREADMEをご覧ください。 また、その他にも多くのタスクがあるので使えそうな物があったらピックアップしてみるといいでしょう。

• Plugins – Grunt: The JavaScript Task Runner

その他Gruntの魅力

なんといっても、JavaScriptベースである為にプラグイン開発が非常に身近にある点だと思います。

cf) Creating tasks – Grunt: The JavaScript Task Runner

JavaScriptに心得のある人ならば、自分が使いやすいようなタスク・プラグインを自前で開発して、 自分好みの開発環境を構築していく事が出来ます。 また、その為に便利なインターフェイスも十分整備されています。 有用なプラグインが書けたら、npmにパブリッシュしておけばいつでも使えますね。

まさにnode様様といったところです。

まとめ

Grunt の概要をざっくり紹介しました。

これだけではそこまで有用と思われないかもしれませんが、 多くのコーダーさんにとって威力を発揮するのは、やはりCSSプリコンパイラのビルドだと思います。 後編ではそのあたりを紹介してみます。

スタイルガイドについて

ざっくり言うとスタイルシートのドキュメントです。

自分一人で完結するその場限りのページなら良いのですが、 複数人のチームで組み込んでいたり、メンテナンス担当が他の方だったりする場合、 プロジェクトのCSSをドキュメント化しておく必要が出てきますね。例えば、

• どのような命名規則や方針で書かれていて
• どこになにがあり
• どのようなモジュールがどこで使えて
• そのモジュールはどうするとどのような挙動を起こすのか

等をまとめておく文書になると思います。 規模によってはかなり骨な作業になりそうです。

StyleDoccoとは

• StyleDocco

StyleDocco generates documentation and style guide documents from your stylesheets.

スタイルシートを読み込んで、自動的にドキュメンテーションを生成してくれるツールです。

その為の記法に従う必要がありますが、 基本的にはCSSの記述の前に、コメント（ /* */ )で、概要文とプレビュー用のHTMLを書くだけです。 もちろんそのままCSSとしても機能します。

インストール

早速インストールをしてみます。 node.jsで動作するので、先に導入しておきましょう。

node.jsが入ったら、npmコマンドを叩くだけです。
※環境によってはsudoや管理者権限が必要だったりします。

$ npm install -g styledocco

使い方

CSSの書き方

前述の通り、ドキュメントの生成にはその為の記法に従う必要があります。

/*
# ボタン

基本的なボタンスタイル。

    <button class="button">ボタン</button>

*/

.button {
    border-radius:4px;
    border:1px solid #ccc;
    background-color:#f9f9f9;
}

• 概要文はMarkdown記法に対応しています。
• プレビュー用のHTMLにはインデントが必要です。
  
  （タブでもいけましたが、一応公式によれば4スペースとの事です。）

生成コマンド

インストールすると styledocco コマンドが使用出来るようになります。 以下は、「css」ディレクトリの中のファイルを元にドキュメントを生成する例。 出力先はデフォルトで「docs」ディレクトリになります。

$ styledocco -n "My Project" css

使いそうな引数オプションはここらへんでしょうか。

• –name -n プロジェクト名（ドキュメントタイトルになります）
• –out -o 出力ディレクトリ（デフォルトはdocs）
• –preprocessor 使用するプリプロセッサ（Sassとかlessのコマンドを渡します）

例えば以下は「My Project」というタイトルで、「styles」フォルダのソースを元に「mydocs」へ出力をし、 プリプロセッサには「lessc」コマンドを使用する事になります。

styledocco -n "My Project" -o mydocs --preprocessor "lessc" styles

cf) StyleDocco – Usage

gruntで自動化など

gruntでwatchして自動化したい場合は、grunt-styleguide等を利用します。 （諸事情により私は使いませんでした）

• indieisaconcept/grunt-styleguide · GitHub

あるいは grunt-shell でシェルコマンドを書いたり、 自分でタスクを書くなどして、うまいこと楽をすると良いでしょう。

その他、細かい使用感など

ページのはじめに謎の空白のボックスが？

ちょっとハマった箇所ですが、ページの一番はじめのセクションで謎の空白ボックスが生まれてしまいました。

概要文のコメントの先頭に改行を挟んでしまうとこうなります。

/*

# これはダメ



/*
# こうしましょう

プレビューHTML前の改行

概要文とHTMLの間は基本的に1行空いていればいいのですが、 概要文がMarkdownのリスト等になっている様な場合は2行以上あけないとプレビューが正常に表示されません。

/*
# ボタン

* リスト
* リスト


    <!--こういったケースは2行あけましょう。-->

プリコンパイラも併せて使うと重たい？

私の携わったプロジェクトではSass+bootstrapで実装をしていた為、 Sassの重さとbootstrapのボリュームが相まってcss自体のジェネレートに少々時間を要しました。 それに加えて、StyleDoccoのドキュメント生成もある程度時間がかかるため、合わせ技で相当遅くなります。 gruntで自動化をしなかったのはその為です。

ただ、ファイル数やボリュームにも因る所が大きいので一概には言えません。 また、逆に最適化をする機会にも繋がるとも言えますね。

ナビゲーションの生成について

ドキュメントのヘッダナビゲーションには、 スタイルシートのファイル毎にメニューが生成されます。 また、フォルダでファイルを分けている場合は、プルダウンメニューになります。

例えばこのような構造にしてあった場合

css/
  ├ common/
  │   ├ foo.css
  │   ├ bar.css
  │   └ baz.css
  ├ components/
  ├ widgets/
  └ README.md

このような感じに出力されます。

ただし、Macでは問題なかったのですが、当方のWindows環境ではサブフォルダを全て無視されてしまいました。 Issueに投げてみたので、何か反応があったらお伝えします。

ドキュメントページのパフォーマンス

生成されたドキュメントページで動作がもたつくな、と感じたので中身をみてみました。

StyleDoccoのドキュメントページは、ページ毎にひとつのHTMLになっています。 CSSやJavaScriptなどの外部リソースはありません。完全にひとつのファイルです。

プレビューの出力はどうやっているのかというと

1. iframeを動的に生成して、そこに自分自身を読み込む
2. 読まれたHTMLでプレビューを生成し、描画する

という処理をHTMLファイルに記述されたJavaScriptで行なっているようです。

JSで動的に生成している関係上、物とボリュームによっては描画や目次の生成などの動作がもたつく場合があります。 が、「単一ファイルでいきたい！！」というポリシーがひしひしと伝わってくるので、これはこういう物だと思って割り切りました。

まとめ

自前のテンプレートでスタイルガイドを書く手もありますが、 うまく用途にマッチするのであれば、こういうツールを使って楽をしていきたいですね。