開発者ドキュメント

開発中のnpmスクリプトの利用

getdocs

現代の開発者として、私たちは開発の速度と効率を改善するためのますます多くのツールにアクセスできます。 おそらく、Node.jsやその他のバックエンドJavascriptツールの人気が高まっている最も影響力のある要因の1つは、開発のすべての段階で使い慣れた構文を使用できることです。

たとえば、タスクランナーは、開発プロセスのありふれた側面を自動化することを唯一の目的とするプログラムです。 Grunt.js 、 Gulp 、 webpack など、非常に便利なさまざまなJavascriptタスクランナーとビルドツールがあります。 強力で知ることは非常に貴重ですが、それほど注目されないが同様に動作し、深く知ることも同様に価値のある別のツールがあります。npmにはスクリプト機能が組み込まれています。

npmスクリプトを使用して開発ニーズをサポートするさまざまな方法を見てみましょう。

Package.json

Nodeのすべてのプロジェクトには、プロジェクトに関するメタデータを含むpackage.jsonファイルがあります。 このファイルには、タイトル、説明、バージョン、依存関係などが含まれています。 このファイルの主な目的は、npmでプロジェクトを公開できるようにすることです。 誰かがnpmから私たちのプログラムをインストールしたいとき、彼らのシステムは私たちが正しく実行するために依存している他のプログラムを知る必要があります。 また、プログラムの動作と構成について特定のことを知る必要があります。 package.jsonファイルからこのすべての情報を取得します。

典型的なpackage.jsonファイルは次のようになります。

{
  "name": "Crispy",
  "version": "1.0.0",
  "description": "Cooked to perfection!",
  "main": "index.js",
  "scripts": {
    "test": "mocha"
  },
  "author": "AlligatorIO",
  "license": "ISC",
  "dependencies": {
    "ws": "^3.3.2"
  },
  "devDependencies": {
    "webpack": "^3.8.1"
  }
}

ご覧のとおり、これは、プロジェクトに関連する情報を含むJSONオブジェクトを含むファイルにすぎません。

この情報の1つは、 scripts セクション。 これらのスクリプトは、開発および公開のライフサイクル全体のさまざまな時点でトリガーされるコマンドです。 最も一般的なnpmスクリプトの2つは start スクリプト、および test 脚本。 前の例では、開始スクリプトが定義されていないことに気付くでしょう。 これは、npmが開始スクリプトのデフォルト値であるためです。 node server.js. つまり、独自のカスタム開始スクリプトを定義しない場合は、次のように入力します。 npm start コマンドラインに入ると、server.jsという名前のファイルが自動的に検索され、見つかった場合はそのファイルがNodeで実行されます。

また、私たちの test スクリプトの値は単に「モカ」です。 Mocha は一般的なJavaScriptテストツールキットであり、インストールすると、 mocha コマンドラインでコマンドを実行します。 この場合、テストスクリプトはそれ以上のことは何もしていません。

さまざまなユースケースをカバーするさまざまなnpmスクリプトがありますが、現在私たちが最も関心を持っているのは、これらのスクリプトを使用して、新しいプロジェクトの開発中に私たちの生活を楽にするさまざまな方法です。

ライフサイクルを理解する

npmスクリプトの能力を解き放つための最初の鍵は、スクリプトを実行するときにnpmが何をしているのかを理解することです。 最初に行うことは、 package.json ファイルをチェックして、そのスクリプトの値を定義したかどうかを確認することです。 持っていることがわかった場合は、スクリプトの他の2つのバージョンを探します。 「前」バージョンと「後」バージョン。 これらのいずれかが見つかった場合は、指定されたスクリプトに関してそれらを実行します。

例：

{
  "scripts": {
    "prestart": "node loadJaw.js",
    "start": "node Gator.js",
    "poststart": "node bite.js"
  }
}

これがnpmがpackage.jsonファイルで見つけたものである場合、スクリプトは順番に実行されます prestart, start、 それから poststart. これをトリガーするために行うのは、入力することだけです npm start コマンドラインで。 これは、プライマリアクションの直前または直後に何かを実行する必要があるさまざまな状況で非常に役立ちます。 開発では、データベースのローカルコピーを起動するために接続するか、ファイルをバンドルする必要がある場合があります。エラーを回避するために、サーバーを起動する前にこれらの処理が行われることを確認する必要があります。

スクリプトを適切に設定した場合は、コマンドを実行するだけです。 npm start 私たちのすべてのニーズを適切な順序で処理できるようになります。

開発モードと本番モード

npmスクリプトを利用する最も便利な方法の1つは、ノードの値を変更することです。 Node_ENV グローバルプロセス変数を介して任意のノードプログラムでアクセス可能な変数。 単に参照する process.env.Node_ENV その値を見つけるために。

function getEnvironment(){
  return process.env.Node_ENV;
}

getEnvironment(); // returns 'production';

多くのフレームワークは、の値を使用します Node_ENV 開発モードで実行するか本番モードで実行するかを決定する変数。 違いは、多くの場合、本番モードはパフォーマンス用に最適化されているのに対し、開発モードはデバッグ用に最適化されていることです。 の値に応じて異なる構成のプログラムを作成することにより、この共通のメカニズムを独自のプロジェクトで利用できます。 Node_ENV 変数。

たとえば、訪問者をサイトに記録したいとします。 本番モードでは、後で参照できるように、新しい各訪問者のIPアドレスをログファイルに記録したい場合があります。 開発モードでは、トラフィックをリアルタイムで分析してバグを整理している可能性があるため、新しい訪問者に関する情報を別のファイルに記録するとともに、トラフィックをコンソールに記録して、発生を監視できるようにします。 これは次のように簡単です。

const fs = require('fs');
const inDevelopmentMode = process.env.Node_ENV === development;

function newVisitor(ip){
  let logMessage = "New Visitor IP: " + ip;

  if(inDevelopmentMode){
    fs.writeFile("development_log.txt", logMessage, (err) => {
      if(err) throw err;
    });
    console.log(logMessage);
  }
  else{
    fs.writeFile("production_log.txt", logMessage, (err) => {
      if(err) throw err;
    });
  }
}

ここでは、fsモジュールを使用してファイルシステムと対話しています。 私たちは参照しています Node_ENV 開発モードにあるかどうかを判断する変数。そうであれば、development_log.txtファイルとコンソールの両方にログを記録します。 本番モードの場合は、コンソールにログを記録せずに、production_log.txtファイルにログを記録するだけです。

しかし、実際にどのように変更するのですか？ Node_ENV 変数？ 1つの方法は、npmスクリプトを使用することです。 package.json ファイル：

{
  "scripts": {
    "start": "SET Node_ENV=development& node server.js",
  }
}

構文は少しおかしいように見え、一見するといくつかの質問を思い起こさせるかもしれません。 これがなぜこのように行われるのかについての説明です。 これを行おうとするときに注意すべき重要であるが予測できないことがいくつかあります。

もちろん、LinuxとWindowsが環境変数を設定する方法の違いは、チームが両方のオペレーティングシステムからのプロジェクトに取り組んでいる場合、非互換性につながる可能性があります。 これを処理する方法はいくつかあります。 コマンドを実行する前にプログラムが実行されているオペレーティングシステムを判別しようとするcross-envなどのスクリプトまたはモジュールを使用するか、オペレーティングシステムごとに異なるnpmスクリプトを使用してそのままにすることができます。どちらを使用するかを覚えておくのは開発者次第です。 どちらの方法も有効ですが、さまざまなコンテキストで同様のことを行う代替のnpmスクリプトを作成するにはどうすればよいでしょうか。

任意のスクリプト

幸いなことに、npmは、独自のカスタム任意のスクリプトを定義できるようにすることで、これを行うための組み込みの方法を提供します。 これらのスクリプトには任意の名前を付けることができ、npmは期待どおりにスクリプトを実行します。 指定された名前の前に「pre」と「post」を追加することにより、トリガーされたときにスクリプトのすべてのライフサイクルバリエーションを実行しようとします。 これにより、開発中に使用できるカスタムスクリプトをいくつでも使用できます。 重要な違いは1つだけです。それは、コマンドラインからスクリプトをトリガーする方法にあります。

ネイティブにサポートされているすべてのnpmスクリプトについて、次のように入力します npm <script-name>、任意のスクリプトをトリガーするには、使用する必要があります npm run <script-name>. それが唯一の違いです。 Linuxユーザーが操作するための変更された開始スクリプトが必要な場合は、 SET 開始スクリプトからコマンドを実行し、選択した名前を付けます。

また、ローカルのMongoDBインスタンスを起動するためのカスタムスクリプトが必要な場合は、次のようにすることができます。

{
  "scripts": {
    "start": "SET Node_ENV=development& node server.js",
    "mongo": "mongod --dbpath=./pathToDatabase/db"
  }
}

今、私たちは使用することができます npm run mongo データベースを起動します。

任意のスクリプトは、さまざまなコマンドシーケンスを自由にトリガーするのに最適です。 たとえば、次のようにします。

{
  "scripts": {
    "test": "mocha",
    "start": "SET Node_ENV=development& node server.js",
    "mongo": "mongod --dbpath=./pathToDatabase/db",
    "launch": "npm test && npm run mongo && npm start",
  }
}

ここに、テスト、mongo、および開始スクリプトをこの順序でトリガーする起動スクリプトがあります。 スクリプトでconcurrentlyなどのパッケージを使用して、アクションを同時に実行することもできます。

{
  "scripts": {
    "start": "concurrently \"node grip.js bacon\" \"node bite.js bacon\""
  }
}

最終的な考え

これを読んで、npmスクリプトを使用して開発ワークフローを支援する方法についてのアイデアが得られたと思います。 私は個人的に start スクリプトは本番環境をトリガーし、任意のを作成します dev 開発環境をトリガーするスクリプト。 このように、 package.json で他に何も変更する必要はなく、準備ができたら本番モードに戻すことができます。使用するのと同じくらい簡単です。 npm start.

モバイルバージョンを終了