-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Files option standardization #54
Comments
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. |
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. |
I would definitely be -1 on the 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. |
@conradz The first suggestion is too verbose. Also |
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. |
Putting everything in perspective, I'm also +1 on grunt "standard". |
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). |
We choose to make keys as sources and values as destinations because it's more intuitive for tasks like
cp
andmv
.Though, for tasks like
concat
users want to specify multiple files to the same destination. With the current syntax, it would be something like: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:If the number of sources get big, people can split them over multiple lines.
Please note that
grunt
standardizesfiles
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
--- 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).grunt
is doing. This will have direct impact on #50.The text was updated successfully, but these errors were encountered: