読者です 読者をやめる 読者になる 読者になる

スクールアイドルです

冷やし中華はじめました

Grunt/Gulpだるい問題私見

そもそもGruntプラグインもGulpプラグインも、プラグイン作者が「Grunt/Gulpであれ使いたいんだけどないからオレ作るわ」という動機で作るわけです。

作者に使い続ける意欲があればアップデートは続きますが、要らなくなったものを延々とメンテナンスするほど作者は聖人君子でもありません。もちろん人間は間違える生き物なので、作られたものがバグもなく想定通りに動くという保証もありません。

Grunt/Gulpでプラグインなんでも揃ってるから便利と我々が言えるのは、このような脆弱な前提の上でであり、Grunt/Gulpのプラグインから利便性を享受するということは、この脆弱な前提に対して暗黙のうちに同意しているということに他なりません。

別にこれはGrunt/Gulpの零細プラグインだからダメという問題ではなく、どのOSSプロダクトも同じ問題を抱えていて、差があるとすれば開発中断やバグフィックス中断の可能性の高低でしかありません。

NPMパッケージ公開に対する障壁が低いNodeのエコシステムにおいてはその弱さが露見しやすく、去年からの利用者の急増がそれを後押ししたのでしょう。幸い、我々が生きている現代はGitHubと各種CIサービスがあるので、パッチ提出のコストもほぼゼロに近似されています。とっととForkするなりPull Request出すなりすればよいと思います。

しかしそもそものこと、Grunt/Gulpにロックインされる開発方法をどうして選んだのでしょうか? 現在のフロントエンド開発の困難さはおそらく、Ruby on Railsと違いレールが敷かれていないことにあります。Gulpの次にBrowserifyが(役割は違うけれども)台頭したように、未だレールはないけれどベターとされる手法が入れ替わり立ち替わり登場しています。このような状況で一つのツールに盲目的に依存することは、それだけでリスクを抱え込むことになります。

もしその理由が「便利ツールGrunt(Gulp)で爆速開発をしよう的な記事を読んで、ハウツーを見たから」程度であれば、きっと次も別のツールで同じことを繰り返した結果幻滅するでしょう。大きな問題は一つの失敗談へと矮小化され、気力と努力でなんとか解決した的な美談になるでしょう。そしてまた別の飛ばし記事を盲信して、便利ツールのマニュアルを暗記するだけになるのです。

何故こんなことを書いたかというと、要は自戒です。

まとめ

  • どんなに大きいOSSプロダクトでも危ういバランスの上に成り立っている
  • 機能が足りない、バグがあると気づいたら恥ずかしがらずにPull Requestを出そう
  • 「Xというツールは最強で開発速度が爆速に」という飛ばし記事を見ても鵜呑みにしない