package.jsonファイルの "scripts"キーの目的は誰か説明できます。についてpackage.jsonの "scripts"キー
角2を学習しているうちに、package.jsonファイルのスクリプトの下に来たので、 はこのキーの使い方がわかりませんでした。
"scripts": {
"postinstall": "npm run typings install",
"tsc": "tsc",
"tsc:w": "tsc -w",
"start": "concurrent \"node ./bin/www\" \"npm run tsc:w\"",
"typings" : "typings"
}
scriptsのキーは、すでに必須のpackage.jsonにプロジェクト固有の自動化スクリプトを定義するのに便利な場所です。これは、開発者がnpm run coverまたはnpm run deployのような単純なものを入力するだけで、非常に複雑な一連のステップ（非常に特定のファイルの場所やプログラムの引数を含む）を開始するのに役立ちます。これにより長いコマンド行の入力を避け、エラーを回避します。例えば、私のプロジェクトの一つは、これらのコマンドが含まれています
"scripts": {
"cover": "cd source/js/jutil && istanbul cover _mocha -- -R spec && open coverage/lcov-report/jutil/index.html",
"test": "cd source/js/jutil && mocha",
"deploy": "(git diff --quiet --exit-code --cached || git commit -a -m 'deploy') && git push heroku master && heroku open",
"start": "gulp start"
}
私はすぐにテスト、カバレッジテストを実行することができ、または単にいくつかの言葉でクラウドホストにデプロイし、詳細なコマンド - を覚える必要がありません行オプションまたはファイルの場所を指定します。
しかし、注意してください。 JavaScript/node.jsコミュニティには、そのような自動化を定義する "ベスト"または "正しい"場所に関する多くの論争があります。
多くの開発者は、gulp,gruntなどの「タスクランナー」/「ビルドシステム」を分離するか、良いUnix makeなどの独立システムに移行する方が好きです。これらのプロジェクトの場合、scriptsタグは空の状態になります。 （デフォルトでnpm initはtestのために少なくとも1つのキーを生成します）。代わりに、gulpfile.js,Gruntfile、またはMakefileを検索する必要があります。
他の開発者は、ビルドシステムの仕組みになったり、ビルド構成を分離したりするという考えを拒否しています。彼らはしばしば "2,3の単純なスクリプト"をpackage.jsonに直接置き、それを1日と呼びます。
私の経験では、「いくつかの簡単なコマンド」は大きな目標ですが、スクリプトの複雑さはすぐにそれを上回ります。これは、ライブリビルドまたはライブリロードが望まれる、またはいくつかのデプロイメントオプションよりも多くの異なるアセットとアセットタイプを持つ大規模なプロジェクトで特に当てはまります。私は通常gulpで重労働に終わってしまいますが、恐らく簡潔にはpackage.jsonに住んでいます。 "あなたのマイレージは異なる場合があります。"
これを参照すると、より良いアイデアが得られますscript in package.json。
[RTFM]（https://docs.npmjs.com）;） – str