Files option standardization

[satazor]

We choose to make keys as sources and values as destinations because it's more intuitive for tasks like cp and mv.

{
  'path/to/src': 'path/to/dest'
}

Though, for tasks like concat users want to specify multiple files to the same destination. With the current syntax, it would be something like:

{
  'path/to/src1, path/to/src2, path/to/src3': 'path/to/dest'
}

Please note that if there is a lot files to concat, things get ugly because we can't split over multiple lines. The only solution would be to create an option in the filter and use it.

Though, if we flip over the arguments like grunt is doing we can actually specify an array like this:

{
  'path/to/dest': ['path/to/src1', 'path/to/src2', 'path/to/src3']
}

If the number of sources get big, people can split them over multiple lines. Please note that grunt standardizes files like this for every situation.

We need to discuss and decide if we want to maintain the current 'standard', opt for some tasks to be src/dst and others to be dst/src or to do it like grunt is doing. This will have direct impact on #50.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/107107-files-option-standardization?utm_campaign=plugin&utm_content=tracker%2F39683&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F39683&utm_medium=issues&utm_source=github).

[marcooliveira]

I feel that coming up with a standard that all tasks must obey will likely create some problems later on. With this in mind, I think this should be up to the task developer to decide if it makes sense to go one way or the other on the task at hand.

As a final note, I see no problem with defining a standard for cases in which it makes no difference to go either way. For this situation, I have no strong opinion.

[satazor]

The developer still has control and might not want to follow the spec in some cases. Still, I think that we should define a 'standard' for this. Lets see what other guys think.

//cc @millermedeiros @sindresorhus @conradz @mklabs

[conradz]

I would definitely be -1 on the { 'src1, src1': 'dest'} syntax. The most flexible way would be like [{ src: ['file'], dest: 'file' }, ...], which would allow per-file options, and multiple output and input files. If #49 is implemented, this structure could easily be generated by the API. Example:

task
  .id('test')
  // ...
  .file('src1', 'src2', 'dest')
  // or
  .in('src1', 'src2').out('dest')
  .in('foo').out('bar')
  .file({ src: [...], dest: ... })

Or any other way of having the API generate it.

[satazor]

@conradz The first suggestion is too verbose. Also files is an option of tasks, and those options are passed in the do(task, config)

[conradz]

Oh, ok was forgetting we need them per sub-task, which the task builder doesn't reach. In that case, I would be +1 on the grunt "standard", since it is much clearer that it is taking multiple tasks.

[satazor]

Putting everything in perspective, I'm also +1 on grunt "standard".

[marcooliveira]

Fine with me, since it's ultimately up to the developer to decide if he should go either way (if something other than the standard is more practical to that specific case).

[marcooliveira]

This will be postponed until the task spec is defined. (by @satazor)