【发布时间】:2013-12-05 20:54:09
【问题描述】:
我正在尝试利用 GruntJS 创建一个跨公司多个团队和项目统一的构建过程。听到的想法是我们为每个应用程序都有一个配置文件,它只指定需要处理的文件以及最后需要将它们连接到哪些包中。所有应用程序的构建过程都是相同的:获取应用程序的配置,使用统一的构建过程处理每个包中的文件。
例如:
- asset.json 配置文件指定了两个捆绑包,“main”带有 1.js + 2.js,“secondary”带有 2.js 和 3.js
- 构建过程对每个包进行预处理、缩小,然后根据包连接成一个 js 文件
- 获取“main.js”和“secondary.js”的输出
我遇到的问题是 Grunt 采用“静态”配置并执行它。我已经抽象出配置的构建,以便我可以动态添加块,但现在我没有看到比逐个循环并为构建过程的每个部分构建一个独特的任务更好的方法对于每个捆绑包,构建要执行的任务队列,然后在构建过程中运行队列中的每个任务。这绝对是可能的,但它需要大量的手工工作,而且似乎很容易坏掉。当我遍历捆绑包时,有没有办法按顺序执行每个任务?有没有更好的方法来实现 config + source in, N bundles out 的相同最终结果?
我想明确一点,我完全知道 Grunt 可以构建多个文件。我要做的是将捆绑数量的规范与构建步骤本身分开。 Grunt 核心必须将这两件事结合在一起,这意味着每个项目都必须进入并更改其构建步骤,而不是外部配置。根据上面的示例,我应该能够将步骤 1 中指定的asset.json 文件换成具有 1、2、3、... N 个捆绑包的任何配置文件,每个捆绑包中有 N 个文件(并可能指定一个“类型”,如脚本或样式)。
【问题讨论】:
标签: gruntjs