这可能是一个FAQ,但浏览文档没有帮助,我放弃了。群组相关的grunt任务配置在一起
我必须运行一个涉及使用其他几个grunt任务的咕task任务。这些任务中的每一个都必须进行不同的配置。事情是这样的:
grunt.initConfig({
clean : {
task1 : ["task1"],
task2 : ["task2"]
},
mkdir : {
task1 : {
options : {
create : ["task1"]
}
},
task2 : {
options : {
create : ["task2"]
}
}
}
});
...
grunt.registerTask("task1", ["clean:task1", "mkdir:task1"]);
grunt.registerTask("task2", ["clean:task2", "mkdir:task2"]);
我可以用做的工作:
grunt task1
这工作得很好,但我不明白为什么“独立写作”的各个步骤都必须驱散了所有配置。此外,如果我有很多这样的任务,我的构建文件将变得不可靠。
所以我的问题:
- 在繁重的说法
,我应该叫 “独立写作”?这是一项任务吗?我应该怎样称呼“mkdir:task1”?是一个子任务吗?任务配置?
如何在这种情况下组织我的gruntfile?我需要为“task1”创建一个不同的npm项目吗?这个项目将如何看待(不要犹豫,指着一个完整的grunt noob编写这样的任务的指南,我很想阅读任何超越'这是我的巨大而不可或缺的gruntfile来观看文件,这不是很好吗? )
感谢
我的意思是“你叫什么东西就像我称之为'task1'的东西”。当然,在现实生活中,它会像“包装”一样,它会有几个步骤,每个步骤都对应于一个咕噜任务的特定配置。 – phtrivier
我的问题是:如果我有十个这样的“进程”,每个进程使用许多不同的grunt-task配置,配置将在我的Gruntfile中进行调整,对吧?可读性/维护性不是很差吗? – phtrivier
例如,使用语义UI的Gruntfile,假设我想了解“grunt docs”的作用;我必须在第90行(子任务列表),第465行(第一次使用'copy'),第239行(使用autoprefix),然后328(第二次使用'copy')之间导航,然后266 (使用'docco')等等......听起来不像是有趣的:( – phtrivier