Gruntfile.jsをサッと開く手段としてeditという簡単なタスクを勢いで書いたんだけど、無意味でつまらないGruntタスクだった。Gruntには様々なタスクがあり、自分でもNode.jsを駆使して自由に書けるので、色々やりたくなる。けれどもグッとこらえて、ワークフローにおける定型作業の自動化に絞った方が、ワークフローと開発環境、そしてGruntfile.jsに優しい。
grunt-contrib-watchを使ったSassの自動コンパイルやLiveReloadのタスクは確かに便利なんだけど、開発から公開までのワークフローの段階として必須というわけじゃない。これらはタスクというよりも環境なので、別に自分好みの環境を作った方が集中できるし、好みでない環境を押し付けずに(そして押し付けられずに)済む。
また、Gruntでなんでもやることに慣れてしまうと、設定されてるしそれで良いかみたいな感じになっちゃう。例えばgrunt-contrib-jshintを使ってJSHintにかけるタスクは大体において最後に行う確認として使われるわけだけど、JSHint自体は開発中にももちろん必要。それぞれにおいて重視すべきチェックポイントは違うので、単純に流用するのはまずい。タスクの設定でそれぞれ分けてどうにかするのはひとつの手ではあるけど、プル・リクエスト用には厳しく、リリース用には少しゆるくチェックしているなどということもあるだろうしとかで、設定はどんどん増えていってしまう。
こういった他のもので開発者ごとに好みにできることだったり、何かしらの流用でとりあえずGruntで実行できるようにしたというだけだったりするようなGruntタスクはつまらない。開発のやり方を強いられてつまらないだったり、Gruntでやる意味がわからなくてつまらないだったり、設定が面倒くさくてつまらないだったり。
様々なことを色々なタイミングで行う便利なGruntfile.jsだと、行うタスクに対して無駄が多いものになりやすい。つまらないタスクを使わないようにすると、設定はシンプルに書けることが多く、テンプレートを使った参照を使えば繰り返し書く必要もあまりない。インストールするGruntタスクを特定の時点、例えばデプロイ前の整理やプロジェクトの下準備というようなワークフローの出入り口に使う自動化だけに絞ると、簡潔で無駄が少なく、把握しやすいGruntfile.jsに自然となってくれる。
これは良くてこれはダメと簡単に評価できる明確な基準があれば良いんだけど、そこまでははっきりしていない。タスクの設定の複雑さや実行速度、規模の大きさなどといった量的な側面から評価するよりも、そのタスクが主に実行されると想定されているタイミングというワークフローにおける時系列的な面から評価する方が良さそう。