web-dev-qa-db-ja.com

NPM対Bower対Browserify対Gulp対Grunt対Webpack

私は最も人気のあるJavaScriptパッケージマネージャ、バンドラー、そしてタスクランナーについての私の知識を要約しようとしています。間違っている場合は訂正してください。

  • npmとbowerはパッケージマネージャです。彼らはただ依存関係をダウンロードするだけで、自分でプロジェクトを構築する方法を知りません。彼らが知っていることは、すべての依存関係を取得した後にwebpack/gulp/gruntを呼び出すことです。
  • bowerはnpmと似ていますが、（再帰的にそれを行うnpmとは異なり）平坦化された依存関係ツリーを構築します。意味npmは各依存関係の依存関係をフェッチします（同じフェッチを数回フェッチする可能性があります）が、bowerは手動でサブ依存関係を含めることを想定しています。フロントエンドとバックエンドにそれぞれbowerとnpmが一緒に使用されることがあります（各メガバイトがフロントエンドで問題になる可能性があるため）。
  • gruntおよびgulpは、自動化できるすべてのものを自動化するタスクランナーです（つまり、CSS/Sassのコンパイル、画像の最適化、バンドルの作成、およびそれの縮小化/変換）。
  • grunt vs. gulp（maven vs gradleまたはconfiguration vs. codeのようなものです）。 Gruntは別々の独立したタスクを設定することに基づいています、各タスクはファイルを開く/処理する/閉じます。 Gulpは必要とするコード量が少なく、Nodeストリームに基づいているため、（同じファイルを開くことなく）パイプチェーンを構築して高速化できます。
  • webpack（webpack-dev-server） - 私にとってそれは、あなたがすべてのJS/CSSウォッチャーについて忘れることを可能にする変更のホットリロードを伴うタスクランナーです。
  • npm/bower +プラグインはタスクランナーを置き換えるかもしれません。それらの能力はしばしば交差するので、gulp +プラグインの上でgrunt/npmを使う必要があるならば、異なる意味合いがあります。しかし、タスクランナーは複雑なタスクには絶対に向いています（たとえば、各ビルドでバンドルを作成し、ES6からES5に移行し、すべてのブラウザエミュレータで実行し、スクリーンショットを作成し、ftpを通じてdropboxにデプロイします）。
  • browserifyを使用すると、ブラウザ用のノードモジュールをパッケージ化できます。 browserify vs nodeのrequireは、実際には AMD対CommonJS です。

質問：

  1. webpack＆webpack-dev-serverとは何ですか？公式ドキュメントにはモジュールバンドルと書いてありますが、私にとってはタスクランナーに過ぎません。 違いは何ですか？
  2. どこでbrowserifyを使用しますか？ノード/ ES6のインポートでも同じことはできませんか？
  3. いつgulp/gruntをnpm +プラグインの上に使用しますか？
  4. 組み合わせを使用する必要がある場合は例を入力してください
gruntjsnpmgulpbowerwebpack
1724
VB_

WebpackおよびBrowserify

WebpackとBrowserifyはほぼ同じ仕事をします。つまり、ターゲット環境で使用されるコードを処理します（主にブラウザですが、他の環境をターゲットにすることもできます） Nodeのような）。そのような処理の結果は、1つ以上のbundles-ターゲット環境に適したアセンブルされたスクリプトです。

たとえば、モジュールに分割されたES6コードを記述し、ブラウザーで実行できるようにしたいとします。これらのモジュールがNodeモジュールである場合、Node環境にのみ存在するため、ブラウザーはそれらを理解しません。 ES6モジュールは、IE11などの古いブラウザーでも機能しません。さらに、ブラウザがまだ実装していない実験的な言語機能（ESの次の提案）を使用している可能性があるため、このようなスクリプトを実行するとエラーがスローされます。 WebpackやBrowserifyのようなツールは、これらのコードをフォームブラウザーに変換することでこれらの問題を解決します。さらに、これらのバンドルに非常に多様な最適化を適用することを可能にします。

ただし、WebpackとBrowserifyはさまざまな点で異なり、Webpackはデフォルトで多くのツールを提供します（たとえば、コード分割）、Browserifyはプラグインをダウンロードした後にのみこれを行うことができますが、両方を使用すると非常に類似した結果が得られます。個人的な好みに帰着します（Webpackはトレンディです）。ところで、Webpackはタスクランナーではなく、単にファイルのプロセッサ（いわゆるローダーとプラグインによって処理されます）であり、タスクランナーによって（他の方法とともに）実行できます。

Webpack Dev Server

Webpack Dev ServerはBrowsersyncに似たソリューションを提供します-開発中のサーバーは、作業中にアプリを迅速にデプロイし、開発サーバーがコードの変更時にブラウザーを自動的に更新するか、変更されたコードをブラウザーに伝播することで、開発の進行状況をすぐに確認できますいわゆるホットモジュール交換でリロードする必要はありません。

タスクランナーとNPMスクリプト

私はGulpを簡潔かつ簡単に書くために使ってきましたが、後でGulpもGruntもまったく必要ないことがわかりました。 NPMスクリプトを使用して、APIを介してサードパーティツールを実行するために、これまで必要だったすべてを実行できたはずです。 Gulp、Grunt、またはNPMスクリプトの選択は、チームの好みと経験に依存します。

GulpやGruntのタスクはJSにあまり馴染みのない人でも読みやすいですが、それは要求と学習を行うもう1つのツールであり、個人的に依存関係を絞り込み、物事をシンプルにすることを好みます。一方、これらのタスクを、サードパーティツールを実行するNPMスクリプトと（適切にはJS）スクリプトの組み合わせに置き換えます（例：Nodeスクリプトの構成と実行 rimraf 目的）より挑戦的かもしれません。しかし、ほとんどの場合、これら3つは結果の点で同等です。

例

例については、この Reactスタータープロジェクト をご覧になることをお勧めします。これは、ビルドおよびデプロイプロセス全体をカバーするNPMとJSスクリプトの素晴らしい組み合わせを示しています。これらのNPMスクリプトは、scriptsという名前のプロパティで、ルートフォルダーのpackage.jsonにあります。そこには主にbabel-node tools/run startなどのコマンドが表示されます。 Babel-nodeはCLIツール（本番用ではありません）で、最初にES6ファイルtools/run（ tools にあるrun.jsファイル）をコンパイルします-基本的にはランナーユーティリティです。このランナーは関数を引数として受け取り、実行します。この場合、start-ソースファイル（クライアントとサーバーの両方）をバンドルし、アプリケーションと開発サーバー（ devサーバーは、おそらくWebpack Dev ServerまたはBrowsersyncのいずれかになります）。

もっと正確に言えば、start.jsはクライアント側とサーバー側の両方のバンドルを作成し、エクスプレスサーバーを起動し、ブラウザ同期を正常に開始した後、執筆時点では次のようになっています（ react starter project を参照してください）最新のコード）。

const bs = Browsersync.create();  
bs.init({
      ...(DEBUG ? {} : { notify: false, ui: false }),

      proxy: {
        target: Host,
        middleware: [wpMiddleware, ...hotMiddlewares],
      },

      // no need to watch '*.js' here, webpack will take care of it for us,
      // including full page reloads if HMR won't work
      files: ['build/content/**/*.*'],
}, resolve)

重要な部分はproxy.targetで、プロキシするサーバーアドレスを設定します。このアドレスは http：// localhost：30 であり、Browsersyncは http ：// localhost：3001 、生成されたアセットは、自動変更検出とホットモジュール交換で提供されます。ご覧のとおり、個別のファイルまたはパターンを備えた別の構成プロパティfilesがあります。ブラウザ同期は変更を監視し、発生した場合はブラウザをリロードしますが、コメントにあるように、WebpackはHMR、彼らはそこで協力します。

現在、このようなGruntまたはGulp構成の同等の例はありませんが、Gulp（およびGruntと多少似ています）を使用すると、gulpfile.jsに個々のタスクを記述できます。

gulp.task('bundle', function() {
  // bundling source files with some gulp plugins like gulp-webpack maybe
});

gulp.task('start', function() {
  // starting server and stuff
});

基本的にスターターキットとほぼ同じことを行いますが、今回はタスクランナーを使用して、いくつかの問題を解決しますが、使用法の学習中に独自の問題といくつかの困難を示します。依存関係が増えれば増えるほど、うまくいかない可能性があります。そして、それが私がそのようなツールを取り除くのが好きな理由です。

948
Dan Macák

2018年10月更新

フロントエンド開発についてまだ不明な点がある場合は、こちらの優れたリソースをご覧ください。

https://github.com/kamranahmedse/developer-roadmap

2018年6月更新

始めからそこにいなければ、最新のJavaScriptを学ぶのは難しいです。あなたが新参者であるならば、より良い概観を持つためにこの優れた書面をチェックすることを忘れないでください。

https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b7

2017年7月更新

最近、2017年にフロントエンド開発に取り組む方法について、Grabチームからの非常に包括的なガイドを見つけました。以下のように確認できます。

https://github.com/grab/front-end-guide

たくさんのツールがあり、それぞれが異なる側面で私たちに利益をもたらすので、私はかなり長い間これを探してきました。コミュニティはBrowserify, Webpack, jspm, Grunt and Gulpなどのツールに分割されています。 Yeoman or Slushについても聞くかもしれません。それは実際には問題ではなく、明確な道を理解しようとするすべての人を混乱させるだけです。

とにかく、私は何かに貢献したいと思います。

1。パッケージマネージャー

パッケージマネージャーは、プロジェクトの依存関係のインストールと更新を簡素化します。プロジェクトの依存関係は、jQuery, Bootstrapなどのライブラリです。サイトで使用され、ユーザーが作成したものではありません。

すべてのライブラリWebサイトの閲覧、アーカイブのダウンロードと解凍、ファイルのプロジェクトへのコピー-これらはすべて、ターミナルのいくつかのコマンドに置き換えられます。

  • NPM の略：Node JS package managerは、ソフトウェアが依存するすべてのライブラリを管理するのに役立ちます。 package.jsonと呼ばれるファイルでニーズを定義し、コマンドラインでnpm installを実行します...その後、BANG、パッケージがダウンロードされ、使用できる状態になります。 front-end and back-endライブラリーの両方に使用できます。

  • Bower ：フロントエンドパッケージ管理の場合、概念はNPMと同じです。すべてのライブラリはbower.jsonという名前のファイルに保存され、コマンドラインでbower installを実行します。

BowerとNPMの最大の違いは、NPMが依存関係ツリーをネストしているのに対して、Bowerでは以下のようにフラットな依存関係ツリーが必要なことです。

バウアーとnpmの違いは何ですか？

NPM

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Bower

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

npm 3 Duplication and Deduplication にいくつかの更新があります。詳細についてはドキュメントを開いてください。

  • Yarn ：JavaScriptの新しいパッケージマネージャー published by Facebookにより、最近NPMよりもいくつかの利点があります。また、Yarnでは、パッケージを取得するために NPM と Bower レジストリの両方を使用できます。以前にパッケージをインストールしたことがある場合、yarnはoffline package installsを容易にするキャッシュされたコピーを作成します。

  • jspm ：SystemJSユニバーサルモジュールローダーのパッケージマネージャーで、動的なES6モジュールローダーの上に構築されます。独自のルールセットを備えたまったく新しいパッケージマネージャーではなく、既存のパッケージソースの上で動作します。すぐに使用できるのは、GitHubおよびnpmで動作します。 BowerベースのパッケージのほとんどはGitHubに基づいているため、jspmを使用してそれらのパッケージをインストールすることもできます。簡単にインストールできるように、一般的に使用されるほとんどのフロントエンドパッケージをリストするレジストリがあります。

Bower とjspmの違いを参照してください： Package Manager：Bower vs jspm

2。モジュールローダー/バンドル

あらゆる規模のほとんどのプロジェクトでは、コードが複数のファイルに分割されます。各ファイルに個別の<script>タグを含めることができますが、<script>は新しいHTTP接続を確立し、小さなファイル（モジュール性の目標）の場合、接続のセットアップに時間がデータの転送よりも大幅に長くなる可能性があります。スクリプトのダウンロード中は、ページ上のコンテンツを変更できません。

  • ダウンロード時間の問題は、単純なモジュールのグループを単一のファイルに連結し、それを縮小することで大部分解決できます。

例えば

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>
  • ただし、パフォーマンスは柔軟性を犠牲にします。モジュールに相互依存関係がある場合、この柔軟性の欠如は圧倒的かもしれません。

例えば

<head>
    <title>Skateboard</title>
    <script src=“connectors/axle.js”></script>
    <script src=“frames/board.js”></script>
    <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
    <script src=“rolling-things/abstract-rolling-thing.js”></script>
    <script src=“rolling-things/wheels/skateboard-wheel.js”></script>
    <!-- but if skateboard-wheel also depends on ball-bearing -->
    <!-- then having this script tag here could cause a problem -->
    <script src=“rolling-things/ball-bearing.js”></script>
    <!-- connect wheels to axle and axle to frame -->
    <script src=“vehicles/skateboard/our-sk8bd-init.js”></script>
</head>

コンピュータはそれをあなたよりも上手く行うことができるので、ツールを使用してすべてを単一のファイルに自動的にバンドルする必要があります。

その後、RequireJS、Browserify、Webpack、SystemJSについて聞いた

  • RequireJS ：JavaScriptファイルおよびモジュールローダーです。ブラウザ内での使用に最適化されていますが、Nodeなどの他のJavaScript環境で使用できます。

例：myModule.js

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

main.jsでは、myModule.jsを依存関係としてインポートして使用できます。

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

そして、HTMLでは、RequireJSでの使用を参照できます。

<script src=“app/require.js” data-main=“main.js” ></script>

CommonJSとAMDの詳細を読んで、簡単に理解してください。 CommonJS、AMD、RequireJSの関係？

  • Browserify ：ブラウザでCommonJS形式のモジュールを使用できるように設定します。したがって、Browserifyはモジュールローダーほどモジュールローダーではありません。Browserifyは完全にビルド時ツールであり、クライアント側にロードできるコードのバンドルを生成します。

ノードとnpmがインストールされているビルドマシンから始めて、パッケージを取得します。

npm install -g –save-dev browserify

モジュールをCommonJS形式で記述します

//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));

そして、満足したら、バンドルするコマンドを発行します。

browserify entry-point.js -o bundle-name.js

Browserifyは、エントリポイントのすべての依存関係を再帰的に検索し、それらを1つのファイルにアセンブルします。

<script src=”bundle-name.js”></script>
  • Webpack ：JavaScript、画像、CSSなどを含むすべての静的アセットを1つのファイルにバンドルします。また、さまざまなタイプのローダーを介してファイルを処理することもできます。 JavaScriptまたはCommonJSモジュール構文でAMDを書くことができます。ビルドの問題を根本的に、より統合された意見のある方法で攻撃します。 Browserifyでは、Gulp/Gruntと、変換とプラグインの長いリストを使用してジョブを完了します。 Webpackは、通常はGruntやGulpをまったく必要としない、すぐに使用できる十分なパワーを提供します。

基本的な使い方は単純ではありません。 BrowserifyのようなWebpackをインストールします。

npm install -g –save-dev webpack

そして、コマンドにエントリポイントと出力ファイルを渡します。

webpack ./entry-point.js bundle-name.js
  • SystemJS ：モジュールローダーです実行時にモジュールを一般的な形式でインポートできます現在使用されています（CommonJS, UMD, AMD, ES6）。 ES6モジュールローダーポリフィルの上に構築され、使用されている形式を検出して適切に処理するのに十分なほどスマートです。 SystemJSは、ES6コード（BabelまたはTraceurを使用）またはプラグインを使用してTypeScriptやCoffeeScriptなどの他の言語をトランスパイルすることもできます。

node moduleとは何か、なぜそれがブラウザ内にうまく適合しないのかを知りたい。

より役立つ記事：

なぜjspmとSystemJSですか？

ES6モジュール性の主な目標の1つは、インターネット上の任意の場所（Github、npmなど）からJavascriptライブラリをインストールして使用することを本当に簡単にすることです。必要なものは2つだけです。

  • ライブラリをインストールする単一のコマンド
  • ライブラリをインポートして使用する1行のコード

したがって、jspmを使用すると、それを実行できます。

  1. 次のコマンドでライブラリをインストールします：jspm install jquery
  2. 1行のコードでライブラリをインポートします。HTMLファイル内で外部参照する必要はありません。

display.js

var $ = require('jquery'); 

$('body').append("I've imported jQuery!");

  1. 次に、モジュールをインポートする前に、System.config({ ... })内でこれらを設定します。通常、jspm initを実行すると、この目的のためにconfig.jsという名前のファイルが作成されます。

  2. これらのスクリプトを実行するには、HTMLページにsystem.jsおよびconfig.jsをロードする必要があります。その後、SystemJSモジュールローダーを使用してdisplay.jsファイルを読み込みます。

index.html

<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
  System.import("scripts/display.js");
</script>

注：Angular 2が適用したように、npmをWebpackとともに使用することもできます。 jspmはSystemJSと統合するために開発されたものであり、既存のnpmソースの上で機能するため、答えはあなた次第です。

。タスクランナー

タスクランナーとビルドツールは、主にコマンドラインツールです。それらを使用する必要がある理由：1つのWordで：automation。 ミニフィケーション、コンパイル、単体テスト、リンティングのような繰り返しタスクを実行するときに行う必要のある作業が少なくなります。

  • Grunt ：開発環境の自動化を作成して、コードを前処理したり、構成ファイルを使用してビルドスクリプトを作成したりすることができます。ここ数年で人気があります。

Gruntのすべてのタスクは異なるプラグイン構成の配列であり、厳密に独立したシーケンシャルな方法で次々に単純に実行されます。

grunt.initConfig({
  clean: {
    src: ['build/app.js', 'build/vendor.js']
  },

  copy: {
    files: [{
      src: 'build/app.js',
      dest: 'build/dist/app.js'
    }]
  }

  concat: {
    'build/app.js': ['build/vendors.js', 'build/app.js']
  }

  // ... other task configurations ...

});

grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
  • Gulp ：オートメーションはGruntと同様ですが、構成の代わりに、ノードアプリケーションのようなストリームでJavaScriptを記述できます。これらの日を好む。

これはGulpサンプルタスク宣言です。

//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
  gulp.src('./scss/ionic.app.scss')
    .pipe(sass())
    .pipe(gulp.dest('./www/css/'))
    .pipe(minifyCss({
      keepSpecialComments: 0
    }))
    .pipe(rename({ extname: '.min.css' }))
    .pipe(gulp.dest('./www/css/'))
    .on('end', done);
});

詳細： https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri

4。足場ツール

  • Slush and Yeoman：それらを使用してスタータープロジェクトを作成できます。たとえば、HTMLとSCSSを使用してプロトタイプを構築し、scss、css、img、fontsなどのフォルダーを手動で作成することを計画しているとします。 yeomanをインストールして、簡単なスクリプトを実行するだけです。その後、ここですべてがあなたのために。

詳細を検索 こちら 。

npm install -g yo
npm install --global generator-h5bp
yo h5bp

詳細： https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express

私の答えは質問の内容と実際には一致しませんが、Googleでこれらの知識を検索しているときは、常に質問が一番上に表示されるので、要約して答えることにしました。皆さんの役に立つことを願っています。

639
trungk18

npmcompare に技術比較があります。

browserifyとgruntとgulpとwebpackの比較

ご覧のとおり、webpackは平均4日ごとにリリースされる新しいバージョンで非常によくメンテナンスされています。しかし、Gulpはそれらの中で最大のコミュニティを持っているようです（Githubには20K以上の星があります）。

それで、他のものの上に１つを選ぶ必要があるならば、私はGulpと共に行きます

49
dcohenb

Npmについてのちょっとしたメモ：npm3は依存関係をフラットにインストールしようとします

https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution

42
DeadWoroz

Yarnは最近言及される価値がある最近のパッケージマネージャです。だから、そこに： https://yarnpkg.com/ /

ああ、それはnpmとbowerの依存関係の両方を取得することができ、他の高く評価された機能を持っています。

12
Ellone

Webpack＆webpack-dev-serverとは何ですか？公式のドキュメントでは、これはモジュールバンドラーですが、私にとってはタスクランナーにすぎません。違いは何ですか？

webpack-dev-server は、Webpack開発者が自分が何をしているかを即座にフィードバックするために使用するライブ再読み込みWebサーバーです。開発時にのみ使用してください。

このプロジェクトは、 nof5 単体テストツールに大きな影響を受けています。

Webpackは、名前が示すとおり、SINGLEpackwebの年齢。パッケージは最小化され、単一のファイルに結合されます（現在もHTTP 1.1時代に住んでいます）。 Webpackは、リソース（JavaScript、CSS、画像）を組み合わせて<script src="assets/bundle.js"></script>のようにそれらを挿入する魔法を実行します。

module bundlerと呼ぶこともできます。モジュールの依存関係、および依存関係を取得してそれらをまとめる方法を理解する必要があるためです。

Browserifyはどこで使用しますか？ node/ES6インポートでも同じことはできませんか？

Webpackと同じタスクでBrowserifyを使用できます。 –Webpackはよりコンパクトです。

ES6モジュールローダー機能 inWebpack2はSystem.importを使用していることに注意してください。ブラウザはネイティブにサポートしています。

Npm +プラグインでgulp/gruntを使用するのはいつですか？

忘れるGulp、Grunt、Brokoli、Brunch and Bower。代わりにnpmコマンドラインスクリプトを直接使用し、ここでGulpのような追加パッケージを削除できます。

var gulp        = require('gulp'),
  minifyCSS     = require('gulp-minify-css'),
  sass          = require('gulp-sass'),
  browserify    = require('gulp-browserify'),
  uglify        = require('gulp-uglify'),
  rename        = require('gulp-rename'),
  jshint        = require('gulp-jshint'),
  jshintStyle   = require('jshint-stylish'),
  replace       = require('gulp-replace'),
  notify        = require('gulp-notify'),

プロジェクトの構成ファイルを作成するときは、おそらくGulpおよびGrunt構成ファイルジェネレーターを使用できます。この方法では、Yeomanまたは同様のツールをインストールする必要はありません。

12
prosti

Webpackはバンドラーです。 Browserfyと同様に、コードベースでモジュール要求（requireまたはimport）を探し、それらを再帰的に解決します。さらに、JavaScriptのようなモジュールだけでなく、CSS、画像、HTML、文字通りすべてを解決するようにWebpackを設定することができます。私がWebpackを特に興奮させるのは、コンパイル済みのモジュールと動的にロードされたモジュールの両方を同じアプリケーションに組み合わせることができるからです。したがって、特にHTTP/1.xを超えると、パフォーマンスが大幅に向上します。ここで例を挙げて説明しました http://dsheiko.com/weblog/state-of-javascript-modules-2017/ /バンドル業者の代わりとしてRollup.js（ https）を考えることができます。 //rollupjs.org/ ）、コンパイル中にコードを最適化しますが、見つかった未使用のチャンクをすべて削除します。

AMDでは、RequireJSの代わりにネイティブのES2016 module systemを使うことができますが、System.jsをロードすることができます（ https://github.com/systemjs/systemjs ）

その上、私はnpmがgruntやgulpのような自動化ツールとしてしばしば使われることを指摘します。 https://docs.npmjs.com/misc/scripts をチェックしてください。私は個人的には他の自動化ツールを避けるためだけにnpmスクリプトを使いますが、過去には私はgruntに非常に興味を持っていました。他のツールでは、パッケージを無数のプラグインに頼らざるを得ません。それはよく書かれておらず、積極的にメンテナンスされていません。 npmはそのパッケージを知っているので、ローカルにインストールされたパッケージのいずれかを次のような名前で呼び出します。

{
  "scripts": {
    "start": "npm http-server"
  },
  "devDependencies": {
    "http-server": "^0.10.0"
  }
}

実際には、パッケージがCLIをサポートしていれば、原則としてプラグインは必要ありません。

9
Dmitry Sheiko