Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature requests for plugin API #271

Open
joliss opened this Issue Jul 9, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@joliss
Copy link
Member

joliss commented Jul 9, 2015

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) - #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 - #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 - #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

This comment has been minimized.

Copy link
Contributor

stefanpenner commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Contributor

stefanpenner commented Jul 9, 2015

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

This comment has been minimized.

Copy link

chadhietala commented Jul 12, 2015

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

This comment has been minimized.

Copy link
Member Author

joliss commented Jul 12, 2015

@chadhietala Can you tell more about your use case?

@chadhietala

This comment has been minimized.

Copy link

chadhietala commented Jul 12, 2015

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

This comment has been minimized.

Copy link

tsing80 commented Aug 18, 2015

+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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.