Closed chadhietala closed 9 years ago
Could you wrap the tree (node) in something, and attach the metadata there?
I'd caution against accessing inputPaths
and inputNodes
from outside a node. They are not part of any "official" Broccoli API - a future broccoli-plugin version could in theory do away with either of them. The way Broccoli communicates with nodes is through an as-of-yet undocumented but fixed hidden API - broccoli-plugin puts a nice, usable layer on top of this.
Yea I could just pass in the meta data with the tree attached to it and then internally peel off the trees and set them on the plugin.
Yea I'm not touching inputPaths
or inputNodes
outside of the plugin.
Thanks Jo, I'll close this issue out.
I really like the new Plugin base class, however I think I'm running up against some things that feel bad. It may be that use case is rare but I thought I would share.
For Ember CLI I've been working on re-writing the build pipeline so that it actually resolves a dependency graph. It uses a series of broccoli plugins to get this done. There are several cases where I would like to know more information about what the tree represents other than it's
inputPath
or having towalkSync
and iterate over it's contents. A more concrete example is something like the following.Internally I'm relying on the fact that the trees and the meta are ordered sets so that when I iterate through either the
inputPaths
orinputNodes
I can do a lookup in themeta
based on the index. So far it's worked out pretty well, but it seems like there might be room to have some primitive for something like this. I've thought about turning both the options and things set by broccoli into immutable data structures on instantiation so I have guarantees about mutation. I trust that broccoli internally will not mutate theinputPaths
array but it's just a precaution.I will admit this is probably one of the most complex broccoli plugins and may just be "doable" but out of the happy path scope.