【问题标题】:Building multiple outputs through the same build process with external config使用外部配置通过相同的构建过程构建多个输出
【发布时间】:2013-12-05 20:54:09
【问题描述】:

我正在尝试利用 GruntJS 创建一个跨公司多个团队和项目统一的构建过程。听到的想法是我们为每个应用程序都有一个配置文件,它只指定需要处理的文件以及最后需要将它们连接到哪些包中。所有应用程序的构建过程都是相同的:获取应用程序的配置,使用统一的构建过程处理每个包中的文件。

例如:

  1. asset.json 配置文件指定了两个捆绑包,“main”带有 1.js + 2.js,“secondary”带有 2.js 和 3.js
  2. 构建过程对每个包进行预处理、缩小,然后根据包连接成一个 js 文件
  3. 获取“main.js”和“secondary.js”的输出

我遇到的问题是 Grunt 采用“静态”配置并执行它。我已经抽象出配置的构建,以便我可以动态添加块,但现在我没有看到比逐个循环并为构建过程的每个部分构建一个独特的任务更好的方法对于每个捆绑包,构建要执行的任务队列,然后在构建过程中运行队列中的每个任务。这绝对是可能的,但它需要大量的手工工作,而且似乎很容易坏掉。当我遍历捆绑包时,有没有办法按顺序执行每个任务?有没有更好的方法来实现 config + source in, N bundles out 的相同最终结果?

我想明确一点,我完全知道 Grunt 可以构建多个文件。我要做的是将捆绑数量的规范与构建步骤本身分开。 Grunt 核心必须将这两件事结合在一起,这意味着每个项目都必须进入并更改其构建步骤,而不是外部配置。根据上面的示例,我应该能够将步骤 1 中指定的asset.json 文件换成具有 1、2、3、... N 个捆绑包的任何配置文件,每个捆绑包中有 N 个文件(并可能指定一个“类型”,如脚本或样式)。

【问题讨论】:

    标签: gruntjs


    【解决方案1】:

    编辑 10/12/13:Nitty Gritty 昨天发布了 an article,这可能是解决您的问题的另一种方法。


    这可以通过将要构建的模块名称作为命令行参数传递并在 grunt 配置中加载整个资产文件来完成。请注意,这是示例代码,我尚未对此进行测试,因此您可能需要为您的情况设置正确的路径等。

    首先将 assets.json 文件更新为纯 JavaScript 文件,然后将其改写如下:

    module.exports = {
        main: ["1.js", "2.js"],
        secondary: ["2.js","3.js"]
    }
    

    接下来,您可以将命令行参数传递给 Grunt,它应该指定 assets.js 中的模块名称之一。示例:

    grunt --bundle=main
    

    现在,您需要在 Gruntfile 中加载 assets.js 文件:

    var assets = require('./assets'); // assuming assets.js is on the same level as your Gruntfile
    

    然后您可以使用以下方法获取参数名称:

    var bundle = grunt.option("bundle");
    

    现在您可以使用bundle 作为您的输出文件名并使用assets.bundle 来获取该捆绑包的数组文件。

    【讨论】:

    • Anzeo,谢谢你的想法,但这不是我真正遇到的问题;我需要维护多个配置(针对不同的项目),每个配置都包含 1 个或多个要处理和打包的文件“包”。开发人员不需要指定要构建的特定捆绑包;这不适用于目录观察者和我们这个项目需要的其他东西。我对每个项目都有一个单独的资产文件(JSON 或 JS)感到满意,但是如何让每个资产文件有多个按顺序构建的包是个问题。
    • 虽然这可能会让我找到答案...文件选项可以采用构建文件的对象...动态构建该列表可能还不错。
    • @JonHartmann 好的,我当时不明白你真正的问题。如果您想出一个解决方案作为您自己问题的答案,请务必发布解决方案。与此同时,我会看看我是否能想到一个正确的答案:)
    • 感谢您的关注……最终,尽管我分解并编写了补充模块,该模块将基本配置处理为最终的“静态”模块,它会根据该操作的需要写出。它很笨重,但我最终决定,其他任何事情都需要深入研究 Grunt 的执行情况。
    • 感谢您抽出宝贵时间回复我。如果我遇到合适的解决方案,我会记得在这里发布。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-12-23
    • 2021-02-18
    • 2019-06-08
    • 2012-04-26
    • 1970-01-01
    • 2013-02-25
    • 1970-01-01
    相关资源
    最近更新 更多