Maybe its just me (can't see anyone else commenting) but I had assumed that fly.concat would work much like gulp-concat - i.e. it was for creating new files that were the concatenation of source files/streams/content rather than for appending results to an existing file. I only discovered the difference (and that tis was the intended behaviour) after i was wondering why one of the files the browser was trying to load (from a long running fly watch process) was 101 MB.
Anyway I dont suppose this is likely to change - I can now see from the examples that the intended way to replicate this use case is to clear the directory/file in the task. I can also see arguments for having concat work this way and not the other. Maybe it could be made more clear in future documentation though. Thoughts?
Maybe its just me (can't see anyone else commenting) but I had assumed that
fly.concat
would work much like gulp-concat - i.e. it was for creating new files that were the concatenation of source files/streams/content rather than for appending results to an existing file. I only discovered the difference (and that tis was the intended behaviour) after i was wondering why one of the files the browser was trying to load (from a long runningfly watch
process) was 101 MB.Anyway I dont suppose this is likely to change - I can now see from the examples that the intended way to replicate this use case is to clear the directory/file in the task. I can also see arguments for having concat work this way and not the other. Maybe it could be made more clear in future documentation though. Thoughts?