While I love the idea, seeing `fly-*` packages makes me sad, although I understand the reasoning. Grunt had the same problem, and Gulp does to some extent, however Browserify and Gulp had the right idea where they allow you to use the direct Browserify package without requiring a wrapper. Those wrappers lag behind the actual library typically, and have their own quirks and debugging which is too much congnitive overhead at times.
That said, this is really interesting way of tackling a build system. I love the use of `exports` and generators make a lot of sense for this sort of control flow; I wrote a "block" system for Wordpress that used generators to allow you to render the blocks in a loop inside a template, pause execution of said loop and render more of the template, then continue on. Basically insertion points for completely dynamic layout and contents.
You are not required to create packages to use Fly! You can simply pass your transformer function to `Fly.prototype.filter` and be done with it. I think plugins should be true thin wrappers to whatever utilities you are trying to incorporate into your build task.
Compare this to gulp where you sometimes need to use vinyl and other abstractions, plus stream wrappers and other deps.
Thanks for the update bucaran! If that's the case, I'm definitely going to dive deep in it; that's exactly what I've been hoping for in a next-gen build-tool (WebPack just doesn't do it for me)!
That said, this is really interesting way of tackling a build system. I love the use of `exports` and generators make a lot of sense for this sort of control flow; I wrote a "block" system for Wordpress that used generators to allow you to render the blocks in a loop inside a template, pause execution of said loop and render more of the template, then continue on. Basically insertion points for completely dynamic layout and contents.