Implement folder support.

[feherzsolt]

Hi,

The earlier Web Essentials had the option to compile multiple files in one action. I really miss being able to compile all less files without having to manage each file separately (including additions / deletions).
I had an idea how something similar might be implemented in the current version. Please check if you find this implementation (or any parts of it) useful. This is also related to #49 .

Thanks,
Zsolt

[madskristensen]

I like the idea a lot, but I think a few modifications are needed. I don't think it makes sense to introduce inputFiles and outputFiles. We can infer that from the value of the existing properties. For instance, the current inputFile should accept globbing patterns like 'assets/less/*.less. So the C# Config object should change the implementation ofInputFileto be anIEnumerableinstead ofstring`.

For outputFile we know if it's a folder if there is either no file extension or the value ends with a /.

That way we get the support for both compiling multiple source files into a single output file as well as compiling multiple source files into multiple output files. I think that is a lot more flexible and it is backwards compatible in the JSON config file.

I added support for globbing patterns in the very similar Bundler & Minifier extension using the Minimatch library.

Thumbs up for tackling this!!! 👍

[feherzsolt]

I have checked Bundler & Minifier and I like the idea of making the inputFile and outputFile properties multi purpose, that would also make configuration more consistent among all the Web Essentials extensions. Thanks for pointing that out.
I think that the first step could be to implement supporting multiple source to multiple output compilations. This can be done by "expanding" globbed Config instances to multiple one to one instances. When that is done multiple source to one outputfile compilations could be also implemented by changing the inputFile to be enumerable instead of a single string. I would suggest separating these steps because the first one requires changes only in the configuration handling while the second one is more broader, since as I see it affects all compiler implementations.
What do you think?

[madskristensen]

I guess it makes sense to separate them. The VSIX project uses the GetAbsoluteOuputFile a lot for various things. There are no unit tests for the VSIX project, so it isn't obvious to catch the required behavioral changes.

GetAbsoluteOuputFile should probably return an array of strings to make sure the VSIX project can correctly function. It needs to check files out of source control and other things.