タスクランナーは、テストの実行、コードのチェック、1つのファイルへの結合、 トランスパイリングなどの同様に有用な作業に関連するルーチンアクションを自動化することにより、Web開発者の生活を大幅に簡素化しました。 もちろん、そのようなツールの必要性は省略しますが、それらがなくても可能ですが、それらは生活を大幅に簡素化し、開発プロセスを改善します。
誰もが何らかの方法でタスクランナーを使用します。誰かが古いグラントを使用し、誰かが徐々にアリーナを一気に去り、 他の多くが npmスクリプト を最大限に使用し ます 。
今日は、最後のすべてを詳細に分析し、機能を加速および拡張する方法を分析します
タスクランナーとしてnpmを使用する理由
以下は主観的な経験であり、究極の真実であるふりをするものではありませんが、それでもナレーションを進める重要な理由です 。
上記のランナーが登場したので、彼らは戦闘で私に試されましたが、それぞれに（もちろん）賛否両論があります。 それらを簡単に検討してください。
多数の送信フィールドのために、プログラムによってそれらを強制的に生成する構成のおかげで、許可のエントリしきい値は低くなります。 Gulpはこの問題を全体として解決します。streamsのおかげで、エントリーのしきい値が高くなり、ユーザーはすべてが内部からどのように機能するかを理解する必要があります。
そのため、助成金から離れ、ストリームを整理し、簡潔なGulpfileを作成し、落ち着いて現在のプロジェクトの開発を続けました。 もちろん、次のアプリケーションのために、Gulpfileをもう一度書きました。 そして、以下のために。 そして、 他の多くの人にとって。
その後、gulp自体とそのプラグインの更新が開始され、次に依存関係が独立して更新されていました 。 もちろん、 パッケージの更新 、脆弱性の修正、バグの修正などを監視するサービスを使用することはできませんが、これは良い開発アプローチではありません。
したがって、ほとんどのランナー料金の主な欠点に遭遇しました。それらは更新する必要があり、依存関係も更新する必要があり、依存関係も依存関係です。 モノリシックアプリケーションの場合、これは問題ではありません。 問題は、アプリケーションの多くの部分があり、それぞれが独立したモジュールであるときに始まります。これは、 node.jsの主要な開発パラダイムではありませんか？
そのため、gulp、gulp-jshint、jshintを更新する代わりに、jshintを直接使用し、頻繁に変更されないコマンドラインインターフェイスを使用して、自分の人生をずっと楽にします。
もちろん、このアプローチには欠点があります。 package.jsonファイルのscriptsセクションにすべてをランダムに押し込むと、すぐに悪魔が足をpackage.jsonます。 したがって、名前に彼らの行動を明確に反映した短いチームを使用する必要があります。
npmスクリプト
npm-scriptsを積極的に使用し始めたとき、私は多くの開発者と同様に、このアプローチの不便さと冗長性を認識しました。たとえば、リンターでチェックを整理する必要がある場合、コードは次のようになります。
{ "lint:jshint": "jshint lib test", "lint:eslint": "eslint lib test", "lint:jscs": "jscs lib test" }
次に、すべてのチェックを実行するスクリプトは次のようになります。
{ "lint": "npm run lint:jshint && npm run lint:eslint && npm run lint:jscs" }
非常に冗長ですが、起動されるスクリプトは3つだけです。
便利なnpmスクリプト
npmスクリプトとの対話を容易にする多くのライブラリがあります。 既存のすべてのソリューションの機能を組み合わせ、同時にメインパラダイムから逸脱しない1つの主要なもの、つまりnpmを使用してスクリプトを実行することを検討しnpm 。
npm-run-all
前の例は、非常に冗長で（許可と口論の場合よりもはるかに短いが、それでも）、読みにくいことが判明しました。 npm-run-allを使用すると、 作業がずっと簡単になります。 これにより、同じことを行うコードは次のようになります。
{ "lint": "npm-run-all lint:jshint lint:eslint lint:jscs" }
（ npm-run-allはより短い名前に安全に置き換えることができます： run-s 、 npm-run-all極端なバージョンはこれをサポートします）
同じことを行います。スクリプトを1つずつ実行します。
npm-run-allは利便性の点ではあまり良くありませんが、アクションの原理によりnpm runから遠くはありません：各コマンドは個別に呼び出され、プロセス全体を著しく遅くします。
高速なnpmスクリプト
私は長い間npm-run-allを使用していましたが、ある時点で、スクリプトの実行がより最適で、高速で、同時に簡単な実装ができることに気付きました。 最初の結果は、利便性を損なうことなく、速度と効率の点で非常に優れていました。
レッドラン
redrunの動作原理は類似物とは大きく異なります。各コマンドを個別に起動する代わりに、すべてのネストされたコマンドを1つの大きなコマンドに結合し、実行のためにシステムシェルに既に転送します。 この最適化のおかげで、 npm-実行速度は大幅に向上しますが、スクリプトを並行して連続して実行することは可能です。 解析後のlintスクリプトの例は次のようになります。
jshint lib test && jscs lib test && eslint lib test
redrunは何ができますか？
スクリプトを連続して、並行して、および混合モードで実行する機能に加えて、redrunはnpm runで始まるすべてのスクリプトの発生とnpm test （プレフィックスおよびポストフィックススクリプトを含む）を解析し、package.jsonのconfigセクションを使用するオプションを残しますまた、スクリプトを実行できるredrunすべての出現を解析します。これにより、最終的にすべてが1つの大きなチームになるため、簡潔で理解可能なスクリプトを作成するためのユニークなツールになります。 また、前述のnpm-run-allとほとんどの機能の互換性、およびnpm （スクリプトの直接実行に関連する部分）にも注意する必要があります。
相互作用
redrunの使用例を考えてみましょう。 インストールを開始するには（特別なことはありません）：
$ npm i redrun -g
次に、 npm init -yを使用してpackage.jsonを作成します。
$ mkdir example $ cd example $ npm init -y Wrote to /home/coderaiser/example/package.json: { "name": "example", "version": "1.0.0", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "coderaiser" "license": "MIT", "description": "" }
テスト用のtapeをインストールし、合格する最も簡単なテストを作成します。
$ npm i tape -D $ cat > test.js 'use strict'; const test = require('tape'); test('some test', (t) => { t.pass(); t.end(); }); ^C
package.jsonファイルのscriptsセクションに、いくつかのセクションを追加します。
{ "test": "tape test.js", "watch:test": "npm run watcher -- npm test", "watcher": "nodemon -w test -w lib --exec" }
次に、 npmを使用してテストを実行しnpm 。
$ time npm test reel 0m6.617s user 0m1.262s sys 0m1.778s
そして今、同じこと、 redrunのみ：
$ time redrun test real 0m2.389s user 0m0.495s sys 0m0.544s
このような単純な例でも、実行速度はほぼ3倍速いことがわかります。
次に、 npm watch:testスクリプトで同じことを試してみましょう。
$ time redrun watch:test > nodemon -w test -w lib --exec tape test.js /bin/sh: 1: nodemon: not found Command failed: nodemon -w test -w lib --exec tape test.js real 0m1.211s user 0m0.208s sys 0m0.332s
ええ、 nodemonインストールしなかったnodemon 、見つけるのにたった1秒しかかかりませんでした。 コマンドが完全にデプロイされ、 nodemon （インストール後）がnpm testではなくtape直接再起動するという事実に読者の注意を引きたいと思います。
npm同じことを試してみましょう：
$ time npm run watch:test > article@1.0.0 watch:test /home/coderaiser/article > npm run watcher -- npm test > article@1.0.0 watcher /home/coderaiser/article > nodemon -w test -w lib --exec "npm" "test" sh: 1: nodemon: not found npm ERR! syscall spawn npm ERR! spawn ENOENT npm ERR! article@1.0.0 watch:test: `npm run watcher -- npm test` npm ERR! Exit status 1 real 0m11.594s user 0m2.181s sys 0m2.849s
npmを使用して、 nodemonインストールされていないことを確認するのに11秒かかりました。
nodemonをインストールします。
$ npm i nodemon -D
もう一度試してみましょう。
$ redrun watch:test > nodemon -w test -w lib --exec tape test.js [nodemon] 1.10.2 [nodemon] to restart at any time, enter `rs` [nodemon] watching: test lib [nodemon] starting `tape test.js` TAP version 13
これですべてが機能するようになりました。オブザーバーが起動し、 testフォルダーとlibフォルダーの変更を監視し、 tape test.jsを再起動します。まさに必要なものです。 同時に、package.jsonのコンパクトスクリプト構文を使用することも可能です。
開発プロセス
RedrunはTDDを使用して記述されているため、機能の追加やバグの修正を行うのは非常に簡単です。 読者が、類似ツールと比較してredrunの作業に非自明で文書化されていない矛盾があることに気付いた場合：ishを作成し、リクエストプールを送信します-修正します。
おわりに
npm意図したことを定期的に実行npm優れたツールです。 node.jsエコシステムは非常に急速に進化しており、 npmこのプロセスの最後のnpm果たしています（ただし、最初の1つです）。 npmがすべてを迅速に行うという事実のためにredrunが不要になる瞬間が来ると思います。 しかし、この瞬間が来るまで、そしてそれをより近づけるために、 npmアシスタントはスクリプトを実行するような難しいが重要な問題で作成されました。