CSSのSource Map

Source Mapは、JavaScriptやCSSをモニョモニョしてなんかするツールのすべてでサポートされていないと、その恩恵は受け切れない。しかしその一方でSource Mapはエンドユーザーに必要なものではないので、開発上必要になるわけではない単純な空白削除等を行うツール程度では生成する意味は無いとも言える。破壊的な、例えばCSSだとCSSプリプロセッサーだけにあれば良いとも言える。

一方でプロダクション環境でもSource Map付きでデバッグできると、バグの特定までの高速化は図れる。系統立てての修正にはならないけれど、まずは特定し修正することが重要であるとは言えるので、やはりSource Mapがサポートされている方がより良いとは言える。

ふりだしに戻る。

僕は破壊的なものでは必ずサポートされているべきで、そうでないものではわざわざ苦労してサポートする程でもないと考えていた。CSSならSassやLESSなどのプリプロセッサーには必須だが、autoprefixerやYUI Compressorなどのポストプロセッサーではあれば便利程度だ、と。

でも、この「あれば便利」はワークフローで変化するとも思うようになった。例えばLESSで開発していると、明示的にコンパイルすることなく開発を行えるので、ビルドに集約されていく。その場合、Source Mapを使ったレビュー(テスト)はプロダクションと同じようなビルドを通してから行えば無駄は少なくなる。こういったケースではSource Mapがあらゆるツールでサポートされている方が都合が良いだろう。

CSSWringでは利用しているPostCSSのSource Map生成機能をそのまま利用できるので、ちゃんと使えば生成はもちろん、既存のSource Mapファイルの更新も可能だ(ということになっている)。このウェブサイトでもSource Mapファイルを吐き、サーバーにも置くようにしたので、その動作は確認できるはずだ。数行ずれることがあるが、特にこれといって複雑なことはしていないのでPostCSS側の問題だろう。

簡単な使い方は以下のようになる。

#!/usr/bin/env node

'use strict';

var fs = require('fs');
var csswring = require('csswring');

var input = 'test.css';
var output = 'test.min.css';

var css = fs.readFileSync(input, {
  encoding: 'utf8'
});
var min = csswring.wring(css, {
  map: true,
  from: input,
  to: output
});
fs.writeFileSync(output, min.css);
fs.writeFileSync(output + '.map', min.map);

csswirng.wring()の第二引数はPostCSSのprocess()関数と同じ引数を取る。mapをtrueにすることによって、Source Mapの生成を必ず行うようになるだろう(自動的に保存されるかは場合による)。fromとtoは処理前・処理後のCSSファイルのパスを指定する。これらをちゃんと指定しないと出力されるCSSに追加されるsourceMappingURLやSource Mapファイル内の参照先パスがおかしくなる。

既存のSource Mapファイルを更新したい場合はmapにそのSource Mapファイルの内容を文字列として渡す。けれど既にSource Mapファイルがあるかどうかを自動的にチェックしてくれる機能があるので、あんまり使うことはない。他にインラインSource Mapなども可能なはずだ。