node.js - 自定义任务运行程序与 gulp、grunt、Webpack、npm CLI 脚本

Question

我想联系其他有经验的 Web 开发人员，了解您对如何最好地处理编译/构建 Web 应用程序的意见。

一点背景。我很久以前就开始使用 grunt 和 browserfy 捆绑我的应用程序。主要只是 JS 端捆绑依赖。我仍在使用普通的 css 和 html。

然后 Gulp 似乎是流行的任务运行程序，所以我切换到新项目。我更喜欢 Grunt，但似乎 Gulp 会获得最常用的奖品。

然后是 Webpack。一开始是多么痛苦啊。就像我们都知道的那样，它不一定是一个任务运行器，更多的是一个捆绑器，但人们用它来做我认为它最初不适合做的事情。

最后，可能结合 Webpack，调用命令行任务的简单 npm 脚本。

最终我的设置变得相当复杂，仅仅使用 Webpack 并没有削减它，所以我制作了自己的自定义 javascript 任务运行程序，并且仍然导入了 Webpack、fs-extra、image magik、node-sass 等包。使用 api 的做所有的图像优化、文件移动、i18n 等。

现在，与其用我自己的自定义任务运行器包装所有这些包，为什么不回到 grunt 或 gulp ......顺便说一句，只使用 npm 脚本并从命令行调用任务太通用了，我需要更多的自定义.

所以现在我想知道你们是做什么的。那些也玩过各种任务运行器、复杂的 Webpack 设置等的人。你是否：滚动你自己的自定义任务运行器，只中继调用 cli 任务的 NPM 脚本，使用高度嵌套的 Webpack 脚本，grunt，gulp，.. . 还有什么？

老实说，到现在（2020 年），我认为 gulp 或 grunt 会逐渐消失，尽管情况似乎并非如此。也许我是少数拥有用于更复杂构建的自定义任务运行器（对于简单构建，npm 脚本 cli 进程），我应该回到 Gulp 或 Grunt ......

对于您为稍微复杂的构建过程选择的方法，我将不胜感激。谢谢

标签： node.jsnpmwebpackgulpgruntjs

Answer 1

每当我选择一个工具时，我通常有两个主要考虑因素：

• 在可预见的未来，该工具将为我节省多少时间/精力/头痛
• 学习这个工具需要多少时间/努力/头痛

对于复杂的构建，Gulp 为我节省了相当多的时间/精力/头痛，并且只需要很少的前期工作。这是一个简单的js工具，公司里的任何人都可以轻松学习和使用。如您所知，它可以（几乎）完成构建复杂项目所需的任何事情。

我在“该工具将来能为我节省多少”中考虑的一个因素，尤其是在快节奏的 javascript 世界中，是我认为该工具将由其所有者维护多长时间。Gulp 团队提供企业支持，积极维护项目，每周有超过 120 万次下载，所以我认为他们会存在一段时间。当然，时间足够长，我们会从工具中获得更多价值，而不是我们为学习它付出的汗水。

对于复杂的构建，根据我的经验，Webpack 需要更多的前期工作。NPM 脚本需要对 gulp 抽象的东西进行更多的研究。在我简单的前期努力与长期价值计算中，Gulp 赢得了复杂的构建竞赛。