gulp使用小结(二)

接上篇文章接Gulp使用小结(一)

内容如下：

首先，偶在gulp-demos上已经提交了个较通用的栗子...俺琢磨半天，原准备分阶段搞些 Gulp 套路，但是写完介个栗子之后，觉得已经能覆盖绝大多数的场景了(懵逼脸.gif)。算哒，当偶偷懒就酱吧，一个套路打天下:)

然后，聊聊这篇值得思考的文章《我为何放弃Gulp与Grunt，转投npm scripts》
上
中
下，
英文原地址奉上：《Why I Left Gulp and Grunt for npm Scripts》

最后，偶来分几个维度扯一下这些构建方式的优劣，尤其是对于 npm scripts。

---

目录

• 《npm scripts》概要
• 《npm scripts》观感简聊
• 优劣一览
  • 执行效率
  • 学习成本
  • 个人收益
  • 多人 VS 单干
• 小结
  • 不美好的Node

---

《npm scripts》概要

这篇文章在 InfoQ 上被分成了三篇，字数其实不多，且如果您对 npm scripts 不了解，很推荐各位去看看，构建的玩法完全不一样。基本内容如下：

• 第一篇分析 Gulp 和 Grunt 的劣势。作者忍痛表示各种忍不鸟，主要集中在以下三点：
  • 问题1 - 对插件作者的依赖
  • 问题2 - 令人沮丧的调试
  • 问题3 - 脱节的文档
• 第二篇描述 npm scripts 的洪荒之力被低估啦。其实 npm scripts 是如何强大和好理解，作者罗列了四点 Gulp 与 Grunt 如此流行的原因：
  • 误解1 - 使用npm scripts需要强大的命令行技巧
  • 误解2 - npm scripts不够强大
  • 误解3 - Gulp的流对于快速构建来说是不可或缺的
  • 误解4 - npm scripts无法实现跨平台运行
• 第三篇吐苦水，作者揭示自己在使用 npm scripts 过程中遇到的痛点和解决之道。 痛点：JSON规范并不支持注释，因此无法在package.json中添加注释。 解决办法如下：
  • 编写小巧、命名良好、单一目的的脚本
  • 分离文档与脚本（比如说放在README.md中）
  • 调用单独的.js文件

阅读这篇文章引起偶很多共鸣，因为工作中处理的事务较琐碎(专业打杂)，所以俺对各种技术木有啥倾向性，神马好用就用神马，正好 npm scripts 、Gulp、Grunt 都是俺使用过或正在使用的方案，那么接下来简单聊聊下偶的观点。

《npm scripts》观感简聊

重点强调一下 —— “存在即合理”。

不管何种技术方案，存在都有其客观原因（如历史原因、编码习惯、虚拟机、分布式、语法糖、编程范型、语言模型等等，要想“编原因”能说的多了去了，劳资越编越高大上有木有），所以建议（更期待）大家以更高的视角去看待这种“某某技术方案更好”的问题，适合项目、适合团队 才是最重要的。

偶们先看第一篇文章，主要是分析 Gulp 和 Grunt 的劣势。如果你对 Node 有了解，那么你会发现，作者虽然在吐槽 Gulp/Grunt，但是，其实这些问题都是 Node 正在努力想解决的问题。再俺看来，其实这也可以折射整个 Node 生态略混乱和不标准带来的影响。

但我们 npm scripts 就可以不用面对这些问题鸟？答：可以少面对，因为至少不用去学习 Gulp 和 Grunt 相关的包，其中很多文档确实令人着急；但根本问题还是一样嘛，一样会遇到 包依赖、调试难、文档差 的问题

必须得承认 npm scripts 的强大和灵活，它不仅提供了基于约定的pre与post钩子（PS：钩子是我眼中 npm scripts 最炫酷的能力），可以使用 Node 生态的一切，更可以使用其他的 Python、PHP、bash 等脚本，给予开发者有更大的施展空间。

下来让我们通过 执行效率、学习成本、收益 等维度，看看这三种方案的优劣，最终取舍问题就交给各位啦，反正我所在的团队啥都用:)

再分享几篇学习 npm scripts 的文章，看完之后你会发现，用其替换 Grunt 和 Gulp 没那么简单，但绝不是太麻烦的事情：

• How to Use npm as a Build Tool
• 前端工具-npm script

优劣一览

• 背景一：按俺这种屌丝的眼光看，《Why I Left Gulp and Grunt for npm Scripts》 的作者 Cory House 是个老外，虽然目前国内前端开发者牛人辈出，与美帝差距不大，但整体水平还是略不如的。其实吧，我想说的是：国内的前端普遍对 bash，Node 不熟悉。

• 背景二：“胜过”旧工具的新工具似乎不停的在问世，不经意间就会蹦出个“闪闪亮的”技术来替代另一个，在前端界尤其是这样。这着实让其他语言的开发者惊呆了，因为“前端”这个方向已经火爆了那么久，但是看情况短期内不会消停，各种洪荒之力还在不停的喷涌，景象喜人。

结合这俩个大背景，让偶们用平和的心态来瞅瞅这俩类(Gulp/Grunt 算一类，npm scripts 算一类)构建工具的优劣吧。

执行效率

效率问题好理解。

• Grunt 年龄比 Gulp稍长，在 Github 第一次提交时间是2011/09/18)；v0.4.0 这个版本开始(2013年2月)，Grunt 开始横扫前端圈
• Gulp 在 Github 第一次提交时间是2013/06/30，俺是2014/08 第一次使用，那时中文文档不多，插件也不多

基于“背景二”，“新”工具的产生必然是想革了“旧”工具的命，而且 Gulp 也做到了(尤其在编译效率方面)。由于 Grunt 的编译过程大量依赖对文件的 I/O 操作，所以 Grunt 编译效率远不如基于 stream 的 Gulp 和 npm scripts；且 Gulp 通过管道(pipe)把各个任务(task)的 输入/输出 串起来，让整个编译过程更容易理解和维护。

再看 Gulp 和 npm scripts，如果是基于 Node 生态，那么理论上执行效率半斤八两，完全依赖对应 Package 的洪荒之力；如果不基于 Node 生态，那么比起来就木有太多意义啦，全凭工程师的脑洞和能力。

学习成本

首先，Grunt 和 Gulp 都足够好上手，不需要多先进的理念和经验，就可以用这俩样工具构建简单的前端项目。但是，Gulp 甚至只有几个 API，这真心够易学的。

偶上一篇《一》文章说过：“个人觉得玩 Grunt 是种写配置的感觉；玩Gulp就是写脚本(task)”。

但是对于 npm scripts 来说，学习成本比上面俩种高了几何倍。时间有限，有关更多的 npm scripts 俺就不多啰嗦啦，下面偶简单罗列下其特点：

• 得熟悉 Node，还有相关的 package.json、npm 等之类。PS：Grunt 和 Gulp 都是前端的范畴，会不会 Node 无伤大雅
• 但凡想稍深入一点，就有必要去了解 bash。PS：亲，npm scripts 可不是 CLI 工具，学会写 Node 脚本才仅仅是开始呢😃
• 了解跨平台知识~

不要被"学习成本"阻挡，接下来偶来说说收益吧。技术的积累肯定都是有用的嘛，比如用来：装逼...

个人收益

收益问题就比较现实了。花了时间去学去研究，光收获成就感可不行，实际收益也要能体现才好是吧，所以嘛...让我们干了这碗鸡汤。

{% highlight Delphi %}
少年苦练 10 年拳术欲下山扬名立万，路遇一使刀汉子，数招后不敌惨败而归……回山后找师傅问话

“师傅，为何我苦练十年还会输？”

“因为你不知道打架不止可以用拳头。”

“可你也没告诉我啊！”

“你只说要学拳法，又没说学打架！”

“那我不学拳法了，我要学打架！”

“那就不只是要学拳法了，打架想要赢就得十八般武艺都学，你未必要门门精通，但你最起码得有这些见识。除此之外，还得学挨打，学疗伤，学逃跑，学追踪，学暗器，学使毒……想赢？哪有那么简单的！”

“那我还能成拳法宗师吗？”

“呵呵，如果你打架再也不会输，谁敢说你不是宗师？”

来源：《JavaScript怎样才算学好？》

梦想总是要有的，万一遇见了鬼呢...

不对不对，万一哪天偶们成为了宗师呢，对吧~

多人 VS 单干

我们再看个更现实的问题 —— 多人开发/独立开发。

单干

• 技术瓶颈就是自己
• 开发和部署的环境较随意，反正坑的是自己。PS：各种配环境真的是大团队里的恶魔
• 文档那都不叫问题，肯写几句代码注释给自己和后来人看，这就已经够意思了

多人

• 如何统一技术栈？人人都会 Node 比较难，人人都懂 shell 就更难了，但是人人都能玩转 Gulp 就简单的多了，只要懂 JavaScript 就行鸟
• 开发环境和生成环境得严谨起来啦，而且但凡要考虑跨平台，npm scripts 强大的洪荒之力会被压制，而且真要对面这个问题，光屡文档就得忙一阵
• 请记住，文档是项目和团队的传承...哦对了，package.json 是 JSON 格式，不支持写注释哦...我想骂脏话：#&！#@#@#！@#（##￥

所以，老夫的建议是：请使用 适合 的技术。

小结

当前 3.9.1 版本的 Gulp API 确实足够简单易懂，但 4.0 版本新增了数个 API。有关新 API 的内容就不说明鸟，Changelog地址：CHANGELOG.md

但是！特么去年劳资就等着这个 4.0，现在已经2016年的6月了，这个 4.0 还特么没有出来...

• Grunt 的优势是插件够齐全，开发中需要的插件都能找到，且足够易学好上手；缺点是可读性差强人意，编译效率略低，项目越大劣势会越明显。PS：插件数5734(2016/06/01记录)
• Gulp 作为 Grunt 的颠覆者，确实更简单、更好上手，stream 的特点也更符合技术趋势，而且编译的效率更优；不过插件数相对 Grunt 略少。PS：插件数2432(2016/06/01记录)

更多有关 Grunt 对比 Gulp，推荐阅读：Gulp vs Grunt PS：这文章貌似我多次推荐，但俺真没收好处费:)

---

学习成本较高可能是 npm scripts 最大的问题了；其次就是跨平台会比较麻烦。

其实我觉得使用 npm scripts 最大的好处就是没有“束缚”！！！

不管上面两种方案做到了如何美好和抽象，其实都是 Node 能力的具体落地，所有的一切都背靠整个 Node 生态完成（PS：当然，偶们得肯定 Gulp 和 Grunt 的价值与意义）。

但如果到了 npm scripts，您等于拥有了操作系统的一切。npm scripts 可以执行 shell，shell 里可以是 Node 程序，甚至是 PHP、Ruby、bash 等等能执行的一切，能玩出什么花样就看自己的脑洞有多大了:)

比如在我司，部署/回滚 上线环境和测试环境，测试用例，后门调试等，都是用 npm scripts 几行代码搞定。

不美好的Node

最后，因为想说说 包依赖 这个事情，所以在这容我多聊五毛钱的 Node，火热无比的它确实不是那么美好(PS：当然不会存在完美的语言嘛)。

经过了 JavaScript 和本身版本号的野蛮生长，略混乱的生态也让不少开发者吃到了苦头。说俩事情：

• 善变的标准 ES5 还是 ES2015(就是ES6)？如果你还不知道指针函数、模板字符串、Set/Map数据结构等等，真心看不懂现在新兴的前端项目。又怎么去解决 callback？是 Promise、Async、Generator 还是其他...如果你不去追最新的标准，分分钟就被现在的年轻人吊打呀:)
• 包依赖 数月前 left-pad 事件(一个名字引发的血案，感兴趣的同学请自行搜索)，硬是搞得 NPM 升级了移除包的规则。升级内容的中文版奉上：Npm更新移除包的规。这一段几次写了删、删了写，吐槽和抱怨不适合我这种阳光 boy。。。算了，都删掉~~贴张国外很火的图片来让大家开心一下吧：

---

因为这些构建工具，前端有了自动持续化的构建过程，越来越多美好的事务正在发生...

有关 Gulp 就说到这吧。我水完了，谢谢:)