众所周知，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等任务运行器都存在以下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来说都有可能存在更多潜在的原因：
使用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等任务运行器所能完成的任务，而且配置更加简单，也更加直接，因为它会直接使用目标工具而不必再使用对目标工具的包装器了。 我认为有如下4点原因造成Gulp与Grunt等任务运行器变得如此流行：
下面我就来按照顺序解释一下这些误解。 误解1：使用npm scripts需要强大的命令行技巧 体验npm scripts的强大功能其实并不需要对操作系统的命令行了解太多。当然了，grep、sed、awk与管道等是值得你去学习的，令你众生受用的技能；不过，为了使用npm scripts，你不必非得成为Unix或是Windows命令行专家才行。你可以通过npm中1000多个拥有良好文档的脚本来完成工作。 比如说，你可能不知道在Unix中，命令rm -rf会强制删除一个目录，这没问题。你可以使用rimraf完成同样的事情（它也是跨平台的）。大多数npm包都提供了一些接口，这些接口假设你对所用操作系统的命令行了解不多。只需在npm中搜索想要使用的包即可，边做边学就行了。过去，我常常会搜索Gulp插件，不过现在则是搜索npm包了。libraries.io是个非常棒的资源。 误解2：npm scripts不够强大 npm scripts本身其实是非常强大的。它提供了基于约定的pre与post钩子： { name: "npm-scripts-example", version: "1.0.0", description: "npm scripts example", scripts: { prebuild: "echo I run before the build script", build: "cross-env NODE_ENV=production webpack", postbuild: "echo I run after the build script" } } 你所要做的就是遵循约定。上述脚本会根据其前缀按照顺序运行。prebuild脚本会在build脚本之前运行，因为他们的名字相同，但prebuild脚本有“pre”前缀。postbuild脚本会在build脚本之后运行，因为它有“post”前缀。因此，如果创建了名为prebuild、build与postbuild的脚本，那么在我输入“npm run build”时，他们就会自动按照这个顺序运行。 此外，还可以通过在一个脚本中调用另一个脚本来对大的问题进行分解： { "name": "npm-scripts-example", "version": "1.0.0", "description": "npm scripts example", "scripts": { "clean": "rimraf ./dist |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
