自定义任务运行程序与 gulp、grunt、Webpack、npm CLI 脚本 [关闭]

Question

我想与其他有经验的网络开发人员联系，就如何最好地处理编译/构建网络应用程序征求您的意见。

一点背景。我很久以前就开始使用 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...

如果您对稍微复杂的构建过程所选择的方法提出意见，我将不胜感激。谢谢

Answer 1

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

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

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

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

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