我为何放弃Gulp与Grunt，转投npm scripts（上）

Posted 2020-10-02 mfmdaoyou

本文来源于我在InfoQ中文站翻译的文章。原文地址是：http://www.infoq.com/cn/news/2016/02/gulp-grunt-npm-scripts-part1

Cory House是“Building Applications with React and Flux”与“Clean Code: Writing Code for Humans”的作者。同一时候也是Pluralsight上众多课程的讲师。他是VinSolutions的软件架构师。在全球培训了为数众多的软件开发人员，主要领域是前端开发与整洁代码等软件开发实践。

Cory是微软MVP、Telerik开发人员专家，同一时候也是outlierdeveloper.com的创始人。眼下。环绕着Gulp、Grunt及npm scripts社区展开了非常多争论，讨论Gulp与Grunt在项目中是否还有继续使用的必要。有人坚持觉得Gulp与Grunt等前端构建工具依旧是不可或缺的，还有些人则觉得Gulp与Grunt是全然不是必需使用的，并且还添加了一层抽象，会导致非常多问题。近日，Cory撰文谈到了他对于Gulp、Grunt与npm scripts的认识。并且觉得在如今的project中，我们全然能够抛弃Gulp与Grunt，使用npm scripts就能够满足项目之所需。

众所周知，Gulp与Grunt是非常多项目所使用的构建工具，他们也拥有非常丰富的插件。

只是。我却觉得Gulp与Grunt是全然不必要的抽象，npm scripts更加强大。并且更易于使用。

我本人是Gulp的粉丝。只是在上一个项目中，gulpfile居然有100多行。并且还使用了不少Gulp插件。我尝试通过Gulp集成Webpack、Browsersync、热载入、Mocha等工具，为什么要这么做呢？这是由于有些插件的文档实在是太不充分了；还有些插件仅仅公开了我所需的部分API。当中有个插件存在一个奇怪的Bug。它仅仅能看到文件的部分内容。

还有一个插件则在输出到命令行时丢失了颜色。

当然了，这些问题都是能够解决的；只是，当我直接使用这些工具时，全部问题都不复存在了。近期，我注意到有非常多开源项目仅仅是使用了npm scripts。因此，我决定又一次审视一下自己的做法。我真的须要Gulp么？答案就是：全然不须要。

我决定在我新的开源项目中仅仅使用npm scripts。

我仅仅使用npm scripts为一个React应用搭建了开发环境与构建流程。想知道这个项目是什么样子的么？看一下React Slingshot吧。如今，相对于Gulp来说。我更倾向于使用npm scripts，以下就来谈谈原因。

Gulp与Grunt怎么了？

随着时间的流逝，我发现诸如Gulp与Grunt等任务执行器都存在以下3个核心问题：

• 对插件作者的依赖
• 令人沮丧的调试
• 脱节的文档

以下就来具体分析上述3个问题。

问题1：对插件作者的依赖

在使用比較新或是不那么流行的技术时，可能根本就没有插件。

当有插件可用时，插件可能已经过时了。

比方说，Babel 6前一阵公布了。其API变化非常大，这样非常多Gulp插件都无法兼容于最新的版本号。

在使用Gulp时，我就感到深深的受伤，由于我所须要的Gulp插件还没有更新。在使用Gulp或是Grunt时。你不得不等待插件维护者提供更新，或是自己修复。

这会阻碍你使用最新版现代化工具的机会。与之相反。在使用npm scripts时。我会直接使用工具，不必再加入一个额外的抽象层。这意味着当新版本号的Mocha、Istanbul、Babel、Webpack、Browserify等公布时，我能够立马就使用上新的版本号。

对于选择来说。没有什么能够打败npm：

图

从上图能够看到，Gulp有将近2,100个插件；Grunt有将近5,400个。而npm则提供了227,000多个包。同一时候还以每天400多个的速度在持续添加。

在使用npm scripts时，你无需再搜索Grunt或是Gulp插件；仅仅需从227,000多个npm包中选择即可了。公平地说，假设所须要的Grunt或是Gulp插件不存在，你当然能够直接使用npm packages。

只是。这样就无法再针对这个特定的任务使用Gulp或是Grunt了。

问题2：令人沮丧的调试

假设集成失败了，那么在Grunt和Gulp中调试是一件令人沮丧的事情。由于你面对的是一个额外的抽象层，对于不论什么Bug来说都有可能存在很多其它潜在的原因：

• 基础工具出问题了么？
• Grunt/Gulp插件出问题了么？
• 配置出问题了么？
• 使用的版本号是不是不兼容？

使用npm scripts能够消除上面的第2点，我发现第3点也非常少会出现，由于我通常都是直接调用工具的命令行接口。

最后。第4点也非常少出现，由于我通过直接使用npm而不是任务执行器的抽象降低了项目中包的数量。

问题3：脱节的文档

一般来说。我所须要的核心工具的文档质量总是要比与之相关的Grunt和Gulp插件的好。比方说。假设使用了gulp-eslint。那么我就要在gulp-eslint文档与ESLint站点之间来回切换。不得不在插件与插件所抽象的工具之间来回切换上下文。Gulp与Grunt的问题在于：光理解所用的工具是远远不够的。

Gulp与Grunt要求你还得理解插件的抽象。

大多数构建相关的工具都提供了清晰、强大，且具有高质量文档的命令行接口。

ESLint的CLI文档就是个非常好的样例。

我发如今npm scripts中阅读并实现一个简短的命令行调用会更加轻松，阻碍更少。也更易于调试（由于并没有抽象层存在）。既然已经知道了痛点，接下来的问题就在于，为何我们觉得自己还须要诸如Gulp与Grunt之类的任务执行器呢？

我相信个中原因应该是因人而异的。毫无疑问。Gulp与Grunt等任务执行器已经出现非常长一段时间了。并且环绕着这些任务执行器的插件生态圈也呈现出欣欣向荣的繁荣景象。依赖于这些插件，非常多日常工作都能够实现自己主动化。并且执行良好。这样，人们就会觉得仅仅有通过这些任务执行器才干实现任务的构建、文件的打包、工作流的良好执行等等。

另外一个原因就是人们对于npm scripts的认识还远远不够。对于npm scripts所能完毕的事情与任务也流于表面。

这也进一步造成了非常多人并没有发现npm scripts能够实现非常多日常开发时的构建任务的结果。我相信随着开发人员对于npm scripts认识的进一步深入。大家会逐步发现原来使用npm scripts也能够完毕Gulp与Grunt等任务执行器所能完毕的任务，并且配置更加简单，也更加直接，由于它会直接使用目标工具而不必再使用对目标工具的包装器了。

在本系列的下一篇文章中，我们就来看看npm scripts为人所忽视的原因，以及使用npm scripts能够完毕哪些事情。