なぜmochaはdevDependenciesになる必要がありますか？

Question

それにもかかわらず、チュートリアルのようなdevDependenciesにあるmochaは十分に論理的です、それはすべてのdev依存関係です。

実際には、-gをインストールすると、mochaをコマンドとして実行できます。そして、私が言うことができる限り、あなたのパッケージに言及されているかどうかはまったく違いはありません。

明示的にリストする必要はありませんか？

Answer 1

オープンソースプロジェクトで作業している場合、目標の1つは他の開発者がすぐに寄稿を開始できるようにすることです。

新しい開発者がテストを実行するだけでなく、プロジェクトをすぐに構築して実行できる可能性が高いことの1つがたくさんあります。そのためには、開発者がプロ​​ジェクトに貢献するために必要なすべてのツールを簡単にインストールする方法を提供することができます。

これには含まれています：

• ビルドツール
• テストツール
• コード品質ツール（リンター）

を一方、プロジェクトのユーザーはするつもりはない可能性がありますそのうちのどれかが必要です。これは、dependenciesとdevDependenciesを分割する正当な理由です。その上で

---

、それはあなたが、例えば、npm testを実行できるように、便利なscriptsを提供するために、あなたのpackage.jsonを編集すると便利です。その後npm testあなたnode_modulesから特定のmochaを実行しようとしている

{ 
    ... 
    "scripts": { 
     ... 
     "test": "mocha -opts mocha.opts ...tests..." 
    } 
} 

：それは次のように指定するのが一般的です。

Answer 2

グローバルにインストールすると、すべてのプロジェクトで1つのバージョンになります。

dev依存関係の場合、各プロジェクトはそのプロジェクト固有のバージョンを使用している可能性があり、プロジェクトは制御された方法で新しいバージョンに移行できます。

他のモジュールがグローバルにではなくプロジェクト固有にロードされているのとほぼ同じ議論です。

Answer 3

mochaをコマンドとして実行する必要がないためです。あなたはnode_modulesからそれを実行することができます：./node_modules/.bin/mocha。

Npmはこれを特別にサポートしています。あなたはpackage.jsonに次がある場合：

"scripts": { 
    "test": "mocha" 
}, 
"devDependencies": { 
    "mocha": "*" 
} 

を次に、あなたがモカがグローバルにインストールされていない場合でも、npm testを実行することができます。

だから、これはどういう意味ですか？まず、開発環境をセットアップするために他の開発者と共同作業する場合は、npm install以上のことをする必要はありません。

第二に、私はより有用だと思う、これはTravisのような他のツールを使ってプロジェクトを統合することを容易にされるなど