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 的认识,并且认为在现在的工程中,我们完全可以抛弃 Gulp 与 Grunt,使用 npm scripts 就可以满足项目之所需。
在本系列的上一篇文章中,我们谈到了 npm scripts 的强大功能以及人们为何会忽略 npm scripts。本篇文章将会介绍 npm scripts 中存在的一些痛点以及解决之道。
痛点
显然,使用 npm scripts 也存在着一些问题:JSON 规范并不支持注释,因此无法在 package.json 中添加注释。不过有一些办法可以突破这个限制:
- 编写小巧、命名良好、单一目的的脚本
- 分离文档与脚本(比如说放在 README.md 中)
- 调用单独的.js 文件
我更偏爱第一种解决方案。如果将每个脚本都进行分解,使其保持单一职责,那么注释就变得不那么重要了。脚本的名字应该能完全描述其意图,就像任何短小、命名良好的函数一样。就像我在“ Clean Code: Writing Code for Humans ”中所说的那样,短小、单一职责的函数几乎是不需要注释的。如果觉得有必要添加注释,那么我会使用第 3 种方案,即将脚本移到单独的文件中。这样就可以利用 JavaScript 组合的强大力量了。
Package.json 也不支持变量。这看起来貌似是个大问题,但实际上并非如此,原因有二。首先,很多时候我们所需的变量都涉及到环境,这可以通过命令行进行设置。其次,如果出于其他原因而需要变量,那么你可以调用单独的.js 文件。感兴趣的读者可以看看 React-starter-kit ,了解这种做法。
最后,还存在一种风险,那就是使用长长的、复杂的命令行参数,这些参数令人难以理解。代码审查与重构是确保 npm 脚本保持小巧、命名良好、单一职责,且每个人都能容易理解的好方式。如果脚本复杂到需要注释,那么你应该将单个脚本重构为多个命名良好的脚本,或是将其抽取为单独的文件。
我们需要证明抽象是有意义的
Gulp 与 Grunt 是对我所使用的工具的抽象。抽象是很有用的,不过抽象是有代价的。它让我们过分依赖于插件维护者与文档,同时随着插件数量的不断攀升,他们也不断引入复杂性。我已经决定不再使用诸如 Gulp 与 Grunt 之类的任务运行器了。
实际上除了我之外,现在已经有不少开发者与我的观点不谋而合,比如说下面这些:
- Task automation with npm run —James Holliday
- Advanced front-end automation with npm scripts —Kate Hudson
- How to use npm as a build tool —Kieth Cirkel
- Introduction to npm as a Build Tool —Marcus Hammarberg
- Gulp is awesome, but do we really need it? —?Gonto
- NPM Scripts for Build Tooling —Andrew Burgess
Cory 的文章一经发出立刻得到了众多开发者的广泛回应,人们纷纷表达了自己的观点,这里摘录出其中一些典型观点以飨各位读者:
Jason Trill 说到:
另一个好处就是对基于 Node 的项目的标准化。如果仅仅通过“npm run”即可运行任务就非常棒了,虽然这些任务只不过是 Gulp/Grunt 的包装器而已。
Dwayne Crooks 说到:
太棒了。我最近一直在思考是否需要在我的工作流中使用 Gulp,并且在项目中使用得越来越少。这篇文章让我相信 Gulp 与其他构建工具是完全没必要的,非常感谢。
Vladimir Agafonkin 说到:
我们在 Mapbox 上有大量的 JavaScript 仓库,他们都使用了 npm scripts,完全没有用上 Gulp 与 Grunt。这么做完全没有任何问题,搭建容易,理解与管理起来也易如反掌。
Martin Olsen 说到:
我在一年前读过了这篇文章 http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ 之后就开始使用 npm scripts 而逐渐放弃 Gulp 了。我喜欢 npm scripts 的简洁性。恕我直言,其唯一的痛点就是无法在脚本中添加注释,并且必须要对双引号进行转义。
Tim Wisniewski 说到:
我也是这么做的,文章的观点与我不谋而合。
Akshay Bist 说到:
不仅仅是 node 包,你可以运行操作系统所能执行的任何脚本。因此,还可以运行 python、bash 脚本等等。
Cecil McGregor 说到:
非常感谢。虽然在工作时我不得不使用 Grunt,不过在家的时候我大部分时间都在使用 npm scripts。很多插件都存在一些问题,浪费了我大量的时间探究问题所在。
Jess Hines 说到:
非常感谢。通常,我们都认为抽象会使得事情变得更加简单,不过我发现 npm scripts 已经足够友好了,并且非常强大。如果需要的话,我会尝试一下文中的做法,加深理解。
adam seldan 说到:
完全同意文中的观点。我最近就一直在使用 npm package.json 脚本,特别是那些大量使用 Node.js 的项目,完全不需要复杂的转换链。如果感觉不太灵便(现在还没有出现,通常情况下,你会提前知道所工作的项目规模,以及其构建步骤),那么引入和学习 Webpack 是一种很好的方式,它在某种程度上要胜于 Grunt 与 Gulp。
Dylan J Harris 说到:
感谢。作为一名任务运行器新手,我已经遇到了文中提到的 3 个问题,因此非常厌恶这种抽象。我打算在接下来的项目中直接使用 npm scripts,非常棒的文章。
Jason Karns 说到:
直接使用 npm scripts 会让我们拥有更多的配置选项;npm 会以环境变量的方式公开 package.json 对象,前缀是 npm_package;npm 拥有定义良好的配置查找方式,因此可以在不同地方定义各种选项,在必要的时候这些选项会被覆盖。
各位 InfoQ 中文站的读者朋友,你在项目中使用过 Gulp、Grunt 等任务运行器么?是否直接使用过 npm scripts?你认为二者之间的差别是什么?npm scripts 是否能够完全取代 Gulp 与 Grunt 呢?当然,Gulp 与 Grunt 由来已久,并且在很多大型项目中都得到了应用;不过,其对插件的依赖一直都为人所诟病,但插件本身也是其一大优势。那么如果要新开发一个项目,你会使用 Gulp 与 Grunt 等任务运行器还是会直接使用 npm scripts 呢?欢迎在下方的评论中提出你的见解并与其他读者一同探讨和交流。
评论 4 条评论