Feature requests for plugin API

[joliss]

I'm collecting feature requests for the plugin API!

I have no concrete plans to implement any of these, but this list helps me make sure that the new API is properly extensible to accommodate adding any of these features without breaking backwards compatibility.

Here's my current list. Please help me brainstorm and add more feature ideas in the comments.

• Debugging: Logging
• Debugging: Nested nodes ("trees" in former terminology) - Making DAG nodes composable #268
• Debugging: "Instantiation stack" to remember where a plugin was instantiated
• Debugging: Better API for communicating plugin names and/or descriptions
• Debugging: Custom names for temporary directories - Tmp dir naming #262
• Performance: "Files changed" structure, so the watcher can tell plugins which files have changed
• Performance: Optional in-memory file system abstraction (directories + buffers/streams) like gulp
• Performance: Persistent cache that survives Broccoli restart
• Performance: Add flag to prevent clearing output directory, so files can be reused
• Feature: Maybe bring back the "cleanup" callback - Dropping the cleanup callback, and whether to handle SIGINT #263
• Feature: Better structured error reporting, e.g. for errors that span multiple files
• Feature: Return multiple errors, so Filter-based plugins can report all errors, not just the first

Credit to @stefanpenner, @rwjblue, @IgorMinar and others for coming up with these.

[stefanpenner]

Specific logging feature (this may already be implicitly called out above) would be logging of invalidations.

Something related to but not limited to how caching writer informs of invalidations.

It would also be good if we used, or where compatible with node-debug. Since many other libs are instrumented with it. When enabled, logging from many modules becomes available.

[stefanpenner]

Not sure how to word this, but as we discussed splitting the DSL structure from the eventual graph. To ensure we only instiatated plugins once we have all information (input/output trees)

[chadhietala]

Would it be possible to make tree creation lazy. What I mean by this is that the tree object does not exist until there are contents in the tree. This may not be possible or non-obvious but I've wanted something like that in the past.

[joliss]

@chadhietala Can you tell more about your use case?

[chadhietala]

In Ember CLI there is a treeFor method that grabs trees out of addons that are used at application runtime. Some of the times an addon does not have any runtime code in them but when I say treeFor('app') I will get a tree representing the app folder, but the app folder doesn't exist on disk but a tree is still created for it. It would be great if either the tree had meta data attached to it if the tree actually contained something or as I mentioned before the tree is created lazily once it contains some contents.

Maybe this should just be fixed at the Ember CLI level by stating before attempting to retrieve a tree.

[tsing80]

+1 for the "Files changed" structure,
If there is a way for broccoli plugin to know the files changed/added/deleted from watcher, plugin such as broccoli-funnel can be optimized that if there is no files is added or deleted, it can be no-oped on the incremental build