以下gulpをやめて、自作のタスクランナー的なものを作った話です。最初にリポジトリへのリンクを載せておきます。appのようにモダンな環境がある中でそういうものが使えないプロジェクトが多々あるので、割とどんなプロジェクトにも対応できるような汎用的な環境をつくってずっと運用していました。具体的には以下のような構成です。server起動なぜgulpをやめようと思ったかgulpのタスクは多くのgulpプラグインをインストールすることで成り立っているのですが、それらのgulpプラグインの多くがあまりメンテナンスされておらず、今後だんだん使えなくなると言われているので、そろそろ何かしら対応しないとなと思っていました。「gulpプラグインの多くがメンテナンスされていない」というのはちゃんと調べたわけではなく、Twitterなどがソースです。そこまで実感がないですが、そういう情報が多くなってきたってことは、いずれはそうなるなと思い、今回実行に踏み切りました。全部webpackでやれないか?今までjsのコンパイルはwebpackを使用していました。正確にはgulp経由でwebpackのタスクを実行していました。webpackではpugなどsassなどもコンパイルできそうな雰囲気があったので、それならばいっそwebpackだけで完結できないかと思いましたが、いろいろ検証したやめました。webpack-dev-serverもあるし。JSもしくはCSSは1つ、jsファイルも一つのような)を作る場合それだけですべて完結できそうな気がしましたが、「HTMLもページごとに物理的に存在、それに合わせてjsファイルやCSSも複数存在する」ようなWebページをwebpackだけで完結させようとすると、どうしても「ムリヤリ感」が強くてスマートではないなと思ってしまいました。以下の記事は結構なるほどな感があって参考にしましたが、やはりいろいろ悩んだ結果やめました。Web制作のコーディングガイドラインとは、美しいコーディング・設計をするためのガイドラインコンテンツです。最後に「webpackで全部やるのはだめだ。compressed"}みたいな感じで記述されていることが多く、今まで自分が使っていた汎用的な環境を見通しよく構築するにはもっと調べる必要があるなと思いました。要は、ソースディレクトリ、出力ディレクトリ、ビルドオプションなどは設定ファイルにまとめつつ共通化し、npm-scriptsの記述はシンプルにできないかなと。"./bbb.js"}のように直接ビルド処理が書かれたjsファイル作ってnpm-scriptsから実行しても良かったのですが、いい機会だと思ったのでnpmパッケージ化しました。公開して不特定多数に使ってもらうようなものでなく、オレオレ開発環境なので、ローカルパッケージとして作りました。install時にnode_modulesディレクトリにローカルパッケージへのシンボリックリンクを貼ってくれます。結局どんなローカルパッケージを作ったのかをざっくりいうと、「タスク設定ファイルに定義されたタスクを実行する機能」です。gulpにかなり似せてます。glupもgulpfile.jsに定義されたタスクを実行するものでした。↓最初に載せていますがリポジトリへのリンクです。クロスプラットフォームで動作するように作ったつもりですが、まだMacOSでしか検証できていません。上記リポジトリには、開発したローカルモジュール、タスク設定、サンプルソースファイルなど、開発環境一式が含まれています。ディレクトリ構成は以下の通りです。(dev/utr/task.js)に記述されており、今回作ったローカルパッケージ自体の機能は非常に少ないです。作ったローカルパッケージは2つで、1つ目は以下の機能を盛り込んだ、タスクランナーの本体です。runner)と名付けました。(BrowserSync)機能もう一つはコマンドラインから上記のutrをラップし、オプション付きで実行できるutr-cliです。production)をしていして実行します。CLIをつくるにあたり、オプションの取得やコマンドの定義などが簡単にできる「commander」というものを使用しています。programswww.npmjs.compackage.jsonを見ていただけるとわかると思いますが、タスク設定ファイル(taskfile)と実行環境(env)を指定してutrを実行しています。},このローカルモジュール起点として、タスクを実行できる仕組みができたので、実際にタスクも組んでみました。今回はタスク構築にかなり時間を取られました。タスクの詳しい内容についてはリポジトリのREADMEに書いておいたので、興味ある方はご覧ください。続いて、タスクを組んでいく上で困ったことがいくつかあったので挙げてみます。困ったこと1:webpackのwatchを走らせたときに、ビルドが走るwebpack.watchですが、ファイルの監視だけを始めてくれればいいのに、最初にビルドが走ってしまいます。これで困っている人がいるらしく、ビルドを走らせないオプションを付けてくれとは言っているようですが、実装されていません。あきらめる機能が提供されていないのであきらめました。watchというタスクにしようと思いました。上記仕様があるので、buildタスクから「webpackによるjsコンパイル」を除いたものを実行し、そのあとwatchタスクを実行すれば、無駄なjsコンパイルがなくなりました。watchタスクだけを実行するとjsのコンパイルが走ってしまいます。これはもうしょうがない。(コロン)」から始まる属性値だとエラーになるようです。:duration="hoge")というやつ。(ダブルクォーテーション)」で囲めばとりあえずは大丈夫だけど、気持ち悪い。resolutionsを使うpug-inheritanceが依存するpug-dependencyが依存するpug-lexerがエラーを吐いている事がわかりました。pug-lexerが古いらしい。試しに手動で少し上のバージョンで上書きして試してみたら、動く。階層の深い依存パッケージのバージョンを指定してインストールってできるのかなぁと調べていたら、どうやらYarnでは標準機能であるらしい。\|qiita.comというわけでpackage.jsonに以下を追記。正確にはpug-inheritanceが依存するpug-dependencyが依存するpug-lexerのバージョンを指定。}ただしこれは、応急処置でしかないのです。pug-depencencyがアップデートされたら動かなくなる恐れがあるので、pug-dependencyにプルリクを出したほうが良いかもしれない。更新がずっとないのでこうしました。npmにも似たような機能を提供しているモジュールがあるけど、柔軟に階層を指定してできるのかは不明。installwww.npmjs.comNodeインストール時にYarnもインストールじゃあとりあえずYarnを導入しようってことでこのあたりも導入。具体的には、Node.jsをインストールしたときに、グローバルに最新のYarnも入れてしまおうということです。pine/github.comついでに、Node.jsの複数バージョン管理に使っていたndenvがどうやら古いとのことで、nodenvに乗り換えました。anyenvを使用してたので乗り換えは簡単でした。本末転倒になっているここまでちゃんと読んでくれた方はうすうす気づいているかと思いますが、「gulpプラグインがメンテされていないからgulpやめる」とか言っているくせに更新日が3年前のパッケージを使ったりしてます。困ったこと3の解決方法:いい勉強になったので良しとするそんなこと言ってたら他人が作ったnpmパッケージを使ってる時点でそういう問題をはらんでいるのと、gulpのブラックボックス的な部分を明示的に自分で組んでいるのでメンテしやすくなったので結果オーライです。「gulpはすごい」プラグインで拡張可能にし、タスクの実態は使う人に委ねる、というフレームワークであるgulpはすごいなと、改めて思いました。個人的には全然現役で使えると思います。使っている人もたくさんいるはずですし。・・・というわけで、gulpやめたのに、結局自分でgulpの簡易版みたいなのを作ってしまった、というお話でした。誰かの役に立つことを祈ります。今回の調査・検証で得るものは多かったです。コレを運用していこうかと思います。ダウンロード#Nodejs#npm#gulp#yarn#taskrunnerこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。サポートいただければ、レッドブルを飲んでより頑張れると思います。サポートをする「スキ」を押してクリエイターを応援しよう!少しでもあなたのお役に立てて嬉しいです。(unshift)東京でフリーランスのdeveloperをやっています。(unshift)IFTTTでSlackとTwitterを連携させて、ギャラリーサイト漁りが快適に。アプリの開発にクロスプラットフォームの...88najeira少しでもあなたのお役に立てて嬉しいです。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。