Add function constructor for files.

[AaronFriel]

This lets files be populated async, e.g.: creating a mock overlay of a live file system. The function may return fs.readFile(...), pull a buffer from S3 or GitHub, or arbitrary other IO actions to return a string or Buffer.

This is not intended to allow populating directories async, it's assumed that crawling directories is cheap relative to reading files.

[tschaub]

Thanks for your interest in contributing @AaronFriel. I can see how it might be convenient to support a function for providing file content. I think it is a bit misleading to describe this as "async" though - since content still needs to be provided synchronously. It might be better described as "lazy" content retrieval - the content is not resolved until the first read call.

It looks like there may be an issue with fs.stat() calls before fs.read(). It would be good to have a test that confirmed things work in that case.

I'm also still curious about a concrete use case. How would you take advantage of this functionality?

[AaronFriel]

I agree re: lazy vs. async distinction.

Apologies for changing the version number, I'm just getting the hang of NPM package references and I figured out how to point it at my repository directly for my own use.

I'm using this functionality along with a static site generator to produce in-memory copies of generated files, using git as a backing store (instead of the filesystem). It's pay-as-you-go instead of pay-upfront.

[tschaub]

@AaronFriel - while I appreciate your work on this, I'm going to close the pull request for now. It is not clear to me that things work properly with fs.stat() with this change (see https://github.com/tschaub/mock-fs/pull/76#discussion_r48664712). If others express a need for this functionality, we can revisit.