Feature metadata refactor

[phated]

I have put together a fairly large refactor that builds upon your latest PR. I wanted to submit it as a PR to your fork so you can take a look at the diff. If you diff this branch to the current master of vinyl-fs, it is actually really clean. Your changes were overall pretty great but I couldn't follow the callbacks being passed around everywhere. I had refactored stuff so the stat call was still in the written callback but then I figured out why you were passing the callbacks around (to handle the outstream.end case). Since streams handle all this stuff we are trying to do rather nicely, I just left them up their own devices and created a closeFd method that is used in writeBuffer and writeDir. I want to refactor the stat method, as it is just a cut-paste of your implementation into a module and add a ton more tests, but I figured I'd send the bulk of it to you now. Feedback is greatly appreciated.

[erikkemperman]

I bet this looks clean against master, most new code is in fresh modules now :-) But as these helpers are exclusively used by lib/writeContents/*, would they not better live in there as well?

A subjective matter, of course, but I found the original back-and-forth between index and writeXXX, with appropriate comments in place, slightly less confusing then having a third level of modules.

More importantly though this looks to me like it does the same thing, so if you're much happier with this structure, great.

Are the changes in test/dest.js and test/symlink.js related to this metadata work?

[phated]

@erikkemperman
Module location: I was planning to reorganize the structure after I sent you this, I just didn't want to mess with the diff prior to sending it your way.
Test changes: no, they were just completely broken when i turned on some other eslint options (no-undef) and weren't testing what they were supposed to (so those features don't actually exist and are breaking changes).

[erikkemperman]

@phated All right, I'm going to have to call it a night -- one more thing I noticed, it is now no longer obvious that the symlink case is not handled yet. I had a TODO somewhere, I think?

And having read the flow in execution order again, for both branches, the original structure strikes me as slightly less fragmented lexicographically -- if that makes any sense -- but of course I spent more time looking at that structure earlier :-P

Maybe @piranna could weigh in?

[phated]

I'll also add @contra

[phated]

Ref gulpjs#151 for clean diff against master

[erikkemperman]

@phated Just to double check, you made this PR to my branch for communication purposes only, right? Or should I merge it at some point?

[phated]

No need to merge it. I'll be rebasing the branch while adding tests and stuff and then I can merge my PR to master. Just wanted to show the diff with yours.

[erikkemperman]

All right, thought so but wanted to be sure.

[erikkemperman]

Metadata stuff finally resolved, closing this!