npmスクリプトの高速化

タスクランナーは、テストの実行、コードのチェック、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 # some test ok 1 (unnamed assert) 1..1 # tests 1 # pass 1 # ok [nodemon] clean exit - waiting for changes before restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これですべてが機能するようになりました。オブザーバーが起動し、 test



フォルダーとlib



フォルダーの変更を監視し、 tape test.js



を再起動します。まさに必要なものです。 同時に、package.jsonのコンパクトスクリプト構文を使用することも可能です。

開発プロセス

Redrun



はTDDを使用して記述されているため、機能の追加やバグの修正を行うのは非常に簡単です。 読者が、類似ツールと比較してredrun



の作業に非自明で文書化されていない矛盾があることに気付いた場合：ishを作成し、リクエストプールを送信します-修正します。

おわりに

npm



意図したことを定期的に実行npm



優れたツールです。 node.js



エコシステムは非常に急速に進化しており、 npm



このプロセスの最後のnpm



果たしています（ただし、最初の1つです）。 npm



がすべてを迅速に行うという事実のためにredrun



が不要になる瞬間が来ると思います。 しかし、この瞬間が来るまで、そしてそれをより近づけるために、 npm



アシスタントはスクリプトを実行するような難しいが重要な問題で作成されました。