Nicolas Bevacqua进行了一个比较JavaScript构建（编绎）系统的任务。他对三巨头： Grunt, Gulp and NPM进行了比较，并讨论了每种的优缺点。
决定采用何种技术总是很难的。一旦遇到问题，你不想推翻你之前的选择。但是你必须选一个，然后让它按照着你的思路做。实施一套构建（编绎）系也是一样的，你应该把它看作一个非常重要的选择，让我们以Grunt为例。
- Grunt有一个完善的社区，即使是在Windows上
- 它不仅仅应用在Node社区
- 它简单易学，你可以随便安装插件并配置它们
- 你不需要多先进的理念，也不需要任何经验
这些都是用Grunt构建编绎工具的充分理由，但我想澄清一点，我不认为Grunt不是唯一最好的选择。还有一些同样流行的选择摆在那里，有些方面可能比Grunt做得更好。
我写这篇文章，以帮助您了解Grunt，Gulp和npm之间的差异，这是我在前端开发工作中使用最多的三种构建工具。
我们先来讨论Grunt擅长的方面
Grunt：好的部分
Grunt最好的一个方面是它的易用性。它能使程序员使用JavaScript构建编绎工具时，几乎不费吹灰之力。你只需要寻找合适的插件，阅读它们的文档，然后安装和配置它。这种易用性意味着大型开发团队，那些不同技能水平的成员，也可以没有任何麻烦的调整编绎流程，以满足项目的最新需求。而且团队并不需要精通Node，他们仅需要配置对象，将不同的任务添加到不同的序列构建编绎流程。
这里有基础足够大的插件库，你会发现自己几乎不需要开发自己的编译任务，这能使您和您的团队能够快速构建开发工具，如果你要快速完成编绎过程这是至关重要的，你也可以采取小步走，逐步完善编译流程的策略。
通过Grunt管理部署也是可行的，因为有许多包已经可以完成这些任务，如 grunt-git, grunt-rsync, 或 grunt-ec2 等等。
那么，Grunt有什么缺陷吗？如果你有一个明显复杂的编绎过程，它可能会变得过于冗长。当开发一段时间以后，它往往很难将编绎过程作为一个整体。一旦你编绎流程任务到达两位数，几乎可以保证，你会发现自己不得不在多个目标(Targets)中跑同一个Task，以便你能够正确地执行任务流。由于任务是需要声明配置的，你也很难弄清楚任务真正的执行次序。
除此之外，你的团队应该致力于编写可维护的代码，当涉及到你的编绎，比如在使用Grunt的情况下，这意味着你需要为每个任务（或者每个编绎流）编写一份独立的配置文件，供你的团队使用。
现在，我们已经了解了Grunt好和不好的方面，以及在何种情况下，比较适合作为你项目的编绎工具。我们再来谈谈npm，它如何被用作构建工具，以及与Grunt有何不同。
将npm视为构建工具
为了将NPM用作构建工具，你需要一个package.json和npm。制定NPM任务就像在脚本中添加属性一样简单。该属性的名称将用作任务名和将要执行的命令。下面的这个build任务将预先检查我们的JavaScript代码中有没有语法错误，例子使用JSHint命令行接口来。在命令行中你可以运行任何你需要的shell。
|
1 2 3 4 5 6 7 8 |
{ "scripts": { "test": "jshint . --exclude node_modules" }, "devDependencies": { "jshint": "^2.5.1" } } |
一旦定义完成，就可以通过下面的命令来运行
|
1 |
npm run test |
需要注意的是npm提供了运行特定任务的快捷方式。比如要运行test，你可以简单地使用npm test并省略动词run。您可以通过一个命令链来将一系列npm run的任务连在一起，构成你的编绎流程：
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "scripts": { "lint": "jshint . --exclude node_modules", "unit": "tape test/*", "test": "npm run lint && npm run unit" }, "devDependencies": { "jshint": "^2.5.1", "tape": "~2.10.2" } } |
您也可以安排一些后台完成的任务，然后让他们同步。假设我们有以下的包文件，我们将复制出一个目录用来放JavaScript文件，以及将我们用Stylus写的样式表文件编绎成CSS。在这种情况下，多个任务一起运行是比较理想的。也可以实现，使用&分隔符即可。
|
1 2 3 4 5 6 7 8 9 10 |
{ "scripts": { "build-js": "cp -r src/js/vendor bin/js", "build-css": "stylus src/css/all.styl -o bin/css", "build": "npm run build-js & npm run build-css" }, "devDependencies": { "stylus": "^0.45.0" } } |
要了解关于将npm用作构建工具的更多内容，你应该先学学写一些Bash命令。
安装NPM的任务依赖
JSHint CLI并不一定要包含在你的系统中，这里有两种安装它的方式。如果你正在寻找直接从命令行中运行的工具，那么你应该在全局范围内安装，使用g标志，如下所示。
|
1 |
npm install -g jshint |
不过，如果您使用的是包在npm run中使用的，那么你就应该把它加到devDependency中，如下所示。这将让npm自动在系统中寻找它所依赖的JSHint安装在了哪里。这方法适用于任何命令行工具中和所有操作系统。
|
1 |
npm install --save-dev jshint |
你其实不仅局限使用CLI工具。事实上，npm能够运行任何shell脚本。让我们来挖一挖！
在npm中使用shell脚本
下面是一个运行在node的脚本，并显示一个随机的绘文字符串(emoji-random)。第一行指定运行环境，该脚本基于Node。
|
1 2 3 4 |
#!/usr/bin/env node var emoji = require('emoji-random'); var emo = emoji.random(); console.log(emo); |
如果你将一个名为emoji的脚本文件放到你项目的根目录中，你必须将emoji-random申报为依赖关系，并将以下脚本命令添加到包文件中。
="_blank" href="http://ourjs.com/detail/53f2be04c1afbc6e30000001">kris
Nicolas Bevacqua进行了一个比较JavaScript构建（编绎）系统的任务。他对三巨头： Grunt, Gulp and NPM进行了比较，并讨论了每种的优缺点。
决定采用何种技术总是很难的。一旦遇到问题，你不想推翻你之前的选择。但是你必须选一个，然后让它按照着你的思路做。实施一套构建（编绎）系也是一样的，你应该把它看作一个非常重要的选择，让我们以Grunt为例。
- Grunt有一个完善的社区，即使是在Windows上
- 它不仅仅应用在Node社区
- 它简单易学，你可以随便安装插件并配置它们
- 你不需要多先进的理念，也不需要任何经验
这些都是用Grunt构建编绎工具的充分理由，但我想澄清一点，我不认为Grunt不是唯一最好的选择。还有一些同样流行的选择摆在那里，有些方面可能比Grunt做得更好。
我写这篇文章，以帮助您了解Grunt，Gulp和npm之间的差异，这是我在前端开发工作中使用最多的三种构建工具。
我们先来讨论Grunt擅长的方面
Grunt：好的部分
Grunt最好的一个方面是它的易用性。它能使程序员使用JavaScript构建编绎工具时，几乎不费吹灰之力。你只需要寻找合适的插件，阅读它们的文档，然后安装和配置它。这种易用性意味着大型开发团队，那些不同技能水平的成员，也可以没有任何麻烦的调整编绎流程，以满足项目的最新需求。而且团队并不需要精通Node，他们仅需要配置对象，将不同的任务添加到不同的序列构建编绎流程。
这里有基础足够大的插件库，你会发现自己几乎不需要开发自己的编译任务，这能使您和您的团队能够快速构建开发工具，如果你要快速完成编绎过程这是至关重要的，你也可以采取小步走，逐步完善编译流程的策略。
通过Grunt管理部署也是可行的，因为有许多包已经可以完成这些任务，如 grunt-git, grunt-rsync, 或 grunt-ec2 等等。
那么，Grunt有什么缺陷吗？如果你有一个明显复杂的编绎过程，它可能会变得过于冗长。当开发一段时间以后，它往往很难将编绎过程作为一个整体。一旦你编绎流程任务到达两位数，几乎可以保证，你会发现自己不得不在多个目标(Targets)中跑同一个Task，以便你能够正确地执行任务流。由于任务是需要声明配置的，你也很难弄清楚任务真正的执行次序。
除此之外，你的团队应该致力于编写可维护的代码，当涉及到你的编绎，比如在使用Grunt的情况下，这意味着你需要为每个任务（或者每个编绎流）编写一份独立的配置文件，供你的团队使用。
现在，我们已经了解了Grunt好和不好的方面，以及在何种情况下，比较适合作为你项目的编绎工具。我们再来谈谈npm，它如何被用作构建工具，以及与Grunt有何不同。
将npm视为构建工具
为了将NPM用作构建工具，你需要一个package.json和npm。制定NPM任务就像在脚本中添加属性一样简单。该属性的名称将用作任务名和将要执行的命令。下面的这个build任务将预先检查我们的JavaScript代码中有没有语法错误，例子使用JSHint命令行接口来。在命令行中你可以运行任何你需要的shell。
|
1 2 3 4 5 6 7 8 |
{ "scripts": { "test": "jshint . --exclude node_modules" }, "devDependencies": { "jshint": "^2.5.1" } } |
一旦定义完成，就可以通过下面的命令来运行
|
1 |
npm run test |
需要注意的是npm提供了运行特定任务的快捷方式。比如要运行test，你可以简单地使用npm test并省略动词run。您可以通过一个命令链来将一系列npm run的任务连在一起，构成你的编绎流程：
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "scripts": { "lint": "jshint . --exclude node_modules", "unit": "tape test/*", "test": "npm run lint && npm run unit" }, "devDependencies": { "jshint": "^2.5.1", "tape": "~2.10.2" } } |
您也可以安排一些后台完成的任务，然后让他们同步。假设我们有以下的包文件，我们将复制出一个目录用来放JavaScript文件，以及将我们用Stylus写的样式表文件编绎成CSS。在这种情况下，多个任务一起运行是比较理想的。也可以实现，使用&分隔符即可。
|
1 2 3 4 5 6 7 8 9 10 |
{ "scripts": { "build-js": "cp -r src/js/vendor bin/js", "build-css": "stylus src/css/all.styl -o bin/css", "build": "npm run build-js & npm run build-css" }, "devDependencies": { "stylus": "^0.45.0" } } |
要了解关于将npm用作构建工具的更多内容，你应该先学学写一些Bash命令。
安装NPM的任务依赖
JSHint CLI并不一定要包含在你的系统中，这里有两种安装它的方式。如果你正在寻找直接从命令行中运行的工具，那么你应该在全局范围内安装，使用g标志，如下所示。
|
1 |
npm install -g jshint |
不过，如果您使用的是包在npm run中使用的，那么你就应该把它加到devDependency中，如下所示。这将让npm自动在系统中寻找它所依赖的JSHint安装在了哪里。这方法适用于任何命令行工具中和所有操作系统。
|
1 |
npm install --save-dev jshint |
你其实不仅局限使用CLI工具。事实上，npm能够运行任何shell脚本。让我们来挖一挖！
在npm中使用shell脚本
下面是一个运行在node的脚本，并显示一个随机的绘文字符串(emoji-random)。第一行指定运行环境，该脚本基于Node。
|
1 2 3 4 |
#!/usr/bin/env node var emoji = require('emoji-random'); var emo = emoji.random(); console.log(emo); |
如果你将一个名为emoji的脚本文件放到你项目的根目录中，你必须将emoji-random申报为依赖关系，并将以下脚本命令添加到包文件中。
