March 25, 2015

Grunt/Gulpで憔悴したおっさんの話

Hello, npm run-script!

先人たちが1年前に通った道で、いろいろいまさらかよって話なんですが。基本的に以下の記事読んだら分かります。要はGulpとかGruntといったモノ使わずにnpm run hogehogeでビルドしよーぜって話です。

// package.json
  "scripts": {
    "start": "npm run start-serve & npm run watch",
    "test": "stylestats public/files/css/maple.css",
    "start-serve": "browser-sync start --server public/ --files public/files/**/*",
    "clean": "rm -rf public/files/css/*",
    "js:min": "uglifyjs public/files/js/app.js > public/files/js/app.min.js",
    "build:js": "browserify assets/scripts/app.js > public/files/js/app.js",
    "css:sass": "node-sass assets/styles/maple.scss public/files/css/maple.css",
    "css:prefix": "autoprefixer -b 'last 2 versions' public/files/css/maple.css",
    "css:comb": "csscomb public/files/css/maple.css",
    "css:min": "csso public/files/css/maple.css public/files/css/maple.min.css",
    "build:css": "bin/build-css.sh",
    "build": "npm run build:js && npm run build:css",
    "lint:js": "jshint assets/scripts/app.js",
    "lint:css": "scss-lint assets/styles/**/*.scss",
    "lint": "npm run lint:js && npm run lint:css",
    "watch:js": "watch 'npm run build:js' assets/scripts/",
    "watch:css": "watch 'npm run build:css' assets/styles/",
    "watch": "npm run watch:js & npm run watch:css"
  }

こんな感じでpackage.jsonに記述して、npm run watchとかコマンド打って使う。

npm run-scriptを使うに至るまでの経緯

率直に言って、おっさん疲れたのです。

ユーザーとして

まぁタスクランナーを使うユーザーとしては、簡単に使いたいよねってのが本音なわけで、2年前はGrunt便利だぜー！ってふれまわったけど、今いざ使ってみようと思うと、あれこれどーするんだっけ？みたいなことが多い。

ましてや、最近はGulpのほうが勢いあるみたいじゃないですか、まぁGulpも使うんですけど、開発しているプロジェクトによって採用しているのがGrunt/Gulpでバラバラになって、Gulpのプロジェクトでgruntってコマンド叩いたりして、『あーここはGulpかー』なんてこともあったりするわけです。

またGruntで使ってるこのプラグインのGulpバージョンないかなーって探すとなかったりする。もしくは作る作る詐欺でリポジトリだけがあってションボリしたりするわけです。

はたまた四天王的に『クククッ、Gruntがやられたようだな、あいつは四天王のなかでも最弱（ｒｙ』とかいって、なんだかBroccoliとかゆー人もいるわけじゃないですか。もう頭いっぱいなんです。おっさん疲れたのです。

普通に元のコマンド叩いたらいいじゃんって思うんです。

プラグイン作者として

若気の至りで、おっさんも昔はよくGruntプラグインを作ったのです。実際に自分のプロジェクトでGruntを使い、必要だったので、プラグイン開発に対する情熱もあったわけですけど、まぁGulpとか使い出したり、普通にコマンド打ってたら、開発するモチベーションがダダ下がりなわけです。

で、そんな時に限って、依存しているパッケージが頻繁にアップデートとかするんですよ。いっぱい新機能とか盛り込んできたりするわけですよ、そしたらissuesで対応しろとか言われるわけですよ。APIも変更してきたりするわけですよ、そしたらissuesで対応しろとか言われるわけですよ。もう追いつけないです。おっさん疲れたのです。

普通に元のコマンド叩けよって思うんです。

依存されるパッケージ作者として

StyleStatsというそこそこ使われるnpmパッケージを作っているのですが、ありがたいことに僕とは別の開発者様がGrunt/Gulpのプラグインを作ってもらっているのです。

ただですね、StyleStats Grunt Pluginのほうが完全に開発が止まってまして、StyleStatsを使いたいGruntプロジェクトのユーザーに人になんて言ったらいいのかなーって、『Gulpの方使ってくださいー』って言うのもなーなんて。

かといって、Gruntプラグインの人に『ちょっとアップデートしてくれよ！』って言うのもなーって。前述の通り、やる気が無い気持ちは痛いほどわかるしなーって。でも更新止まってから、こちらとしてはいっぱいいろんな機能リリースしてるからみんなに使って欲しいしなーって。

僕がPR送ればいいのかもしれないけど、俺もGruntのプラグイン開発ってどうするんだっけって感じだし。そもそもPR送ってもマージしてくれるのか。てか飽きたならリポジトリをtransferしてくれないかなーって。そうやって気を使うのダルいんですよ、おっさん疲れたのです。

普通に元のコマンド叩いてくださいって思うんです。

npm run-scriptの抑えどころ

ということで、npmで元のコマンド叩いたら皆しあわせってことでnpm run-script使おうぜって話。そんな難しいことはないです。基本的には各コマンドをpackage.jsonに記述していくだけです。ざっくりだけどプロジェクトで使う例としてはこんな感じかな。

t32k/maple/package.json

（久しぶりのMaple!!一応、Gruntバージョンも残してある）

ファイル監視はどーするの？：

mikeal/watch を使ってね。

"watch:css": "watch 'npm run build:css' assets/styles/"

複数タスク実行はどーするの？：

直列に実行するときは&&でつないでね。

"build": "npm run build:js && npm run build:css"

並列に実行したいときは、&でつなぐか、parallelshellを使ってね。

"watch": "npm run watch:js & npm run watch:css"
"watch": "parallelshell 'npm run watch:js' 'npm run watch:css'"

スクリプトが長すぎるよ！

シェルファイルに分割するといいよ。

#!/bin/bash
npm run css:sass & npm run css:prefix & npm run css:comb & npm run css:min

chmod +xしとく。

"build:css": "bin/build-css.sh"

または、設定系のオプションは、configフィールドに記述して、scriptsフィールドで、$npm_package_config_NAMEのようにして使う。が、$npm_package_configって！長い！

  "config": {
    "stylestats": "path/to/configuration.json"
  },
  "scripts": {
    "test": "stylestats app.css --config $npm_package_config_stylestats",

はたまた、npm@2.0以上のユーザーであれば、Passing Argumentsというナウい機能を使う。

"scripts": {
  "test": "mocha test/",
  "test:xunit": "npm run test -- --reporter xunit"
}

上記のように、--を使うことでnpm testのあとにコマンドをつなげられる。

Windowsユーザーは？

win-bash使ってもらうとか、UNIX系のコマンド系をラップしてるnpmパッケージ使って（例：rm -rf > rimraf）npm scriptを書くよう心がけるとか、とりまがんばってね。

まとめ

そうゆうわけで、Gulp/Gruntを通さなければプラグインの依存パッケージの更新追随を待たなくてもいいし、Node.js/npmに関する知識とかUNIXに関する知識は、数ヶ月で変わることもないので、変化に適応できない私みたいなおっさんにも優しいんじゃないんでしょうか。ちょっと複雑なことやろうとすると、Node.jsのコードを書かないとできないかもしれないけど、きっと心の優しい誰かがその素晴らしい見聞を共有してくれると思うのです。おっさんは気長に待つのです。