Provide API for updating files on other tasks

[cgross]

Inside tasks, grunt gives us this.files which is a nice abstraction from the different ways files can now be specified (old way, new way with src in target, new way with src in target.files). I find myself often writing tasks to read things and need to update the config on another task (e.g. read the html script tags and put them into concat or uglify).

Its hard to write this code because you have to account for all the different ways the src files can be configured.

It would be beneficial if grunt abstracted that away when trying to update the config, the same way it abstracts it when your reading it with this.tasks.

Ideally I'd specify the task, target, and a dest file I want to add one or more src files to. Grunt would then add to the config if it existed or create the config (with defaults) if it didn't.

[shama]

You can do grunt.config(['concat', 'target', 'src'], ['new/files/*']) to update the files on another task/target.

[cgross]

I think you missed the point. Setting a config is easy, but updating an existing config that may be using any one of the ways that you may specify files is hard. You can specify files like:

concat: {
  'dist/concated.js': ['src1.js','src2.js'],
  dist: {
    src:['src1.js','src2.js'],
    dest:'dist/concated.js'
  },
  dist2: {
    files: {
      'dist/concated.js':['src1.js','src2.js']
    }
  }
}

All 3 are equivalent. There's also the ability to specify a single string as the src instead of an array when you only have one file.

When adding to an existing config, you have to be aware of all these nuances. This is something that would be nice to be handled internally by grunt.

[cowboy]

What's the use-case for programmatically modifying src/dest file information in an existing task?

[cowboy]

Better yet, instead of modifying existing src/dest file information, you could just completely overwrite it with the most verbose format.

[shama]

Also I think this should only be done by a user and not by a task author or 3rd party task. As a user, I don't want other tasks modifying my config without me. If only the user is modifying the config then it's easy to use the existing API to modify their own config.

[cgross]

The use case I have is to read the references from the html file and append those to an existing config.

My project has a mixture of less and css files. I need to have the less compiled and then concated/min-ed together with the css. So I read the less references, pass them to the less task and run less. Then I read the css references and I need those references added together with the produced less css file. Then cssmin can run on those together.

Its the cssmin config that needs to have a both the dynamic config (reading the css refs from html) and a manual config (the compiled less css file).

As a user I want this behavior and using my dom munger task, you specifically have to ask for this. I doesn't just happen w/o your knowledge.

[shama]

Ah I see. How about doing the reverse? Have dom_munger modify it's own config with grunt.config(['dom_munger', 'options', 'files', 'css'], ['style.css']). Then a user can target other tasks at it with:

concat: {
  munge: {
    src: ['<%= dom_munger.options.files.css %>'],
    dest: 'dist/style.css'
  }
}

Then any task would work with dom_munger.

[cgross]

hmm. i hadn't thought of that. But would this work:

concat: {
  munge: {
    src: ['compiled.css','<%= dom_munger.options.files.css %>'],
    dest: 'dist/style.css'
  }
}

Wouldnt that cause src to be an array with 2 values, second being another array?

If that does work I'm happy to go that route.

[shama]

Yep that will work. It will flatten and expand it (so even adding patterns there **/* will work).

The only issue is if concat:munge is ran without running dom_munger first, it will complain about dom_munger.options.files.css not existing. So you might want to preconfigure it first when your task is loading:

module.exports = function(grunt) {
  grunt.config(['dom_munger', 'options', 'files'], {js: [], css: []});
  // then all the grunt.registerTask stuff
};

That way it would simply skip any that didn't exist unless of course, having a warning is desired.

[cgross]

Ok awesome. I'll do that thanks.

I'll allow the user to configure where the list is written so the warning is good.