Given an in-memory fs tree representation, we'll have functions to do the following:
- read a directory on disk into a virtual fs tree
- write a virtual fs tree to a directory on disk
- also, apply an incremental update to an existing directory given an old and new fs tree
- compute a diff between two virtual fs trees
When chaining an in-memory plugin to an on-disk plugin, or vice versa, a future Broccoli builder will automatically call these functions to translate back and forth.
Also, we'll add an in-memory mode to broccoli-plugin. When broccoli-plugin is used by an old Broccoli builder that doesn't support in-memory plugins, it will call these functions as well so that the builder sees files on disk.
This means that we can experiment: We can add an experimental in-memory mode to broccoli-plugin (or a fork) and freely iterate on the API with breaking changes. Only once we "bless" it, by advertising it through a feature flag and adding support to Broccoli core, will we have to maintain compatibility.
While we experiment thus, using an in-memory mode with broccoli-plugin, but without support in Broccoli core, we will automatically
- get the performance win from incremental output updates (basically what Stef has already implemented), but
- not yet get the win from staying completely in-memory and passing the in-memory structure between plugins.
Please keep me cc'ed on the API drafts you come up with :)