Closed mikehaas763 closed 9 years ago
This should be it's own custom registry. A single custom registry isn't supposed to be a catch all for everyone's custom use case.
I think maybe you can combine the 2, so your child gulpfiles all use your custom registry which provides access to the config, and gulp-hub handles loading the multiple gulpfiles from a central one?
@frankwallis you are correct, you would use gulp.registry
on gulp-hub first to load all the child gulpfiles and then you would use it on the metadata binding registry. Each time gulp.registry
is called with a new registry, it calls set
on the new registry for each task already registered.
Being a catch-all kitchen sink and providing a handful of useful features that cover many common scenarios are two very different things. With that said, I'm not saying that I know configuration binding to be a common use case.
I did read that set
is called for each task already registered in the docs, but didn't really understand at the time what that meant. So that's an interesting feature for extending the functionality of tasks and something I may use. Are there any APIs in the registry implementation to compose registries?
The composition "feature" is exactly as you already stated, you just call gulp.registry
multiple times and everything works as expected. As everything with gulp, things should be tiny and composable, which is why I think this feature shouldn't go into gulp-hub.
I started creating my own registry implementation according to https://github.com/phated/undertaker#sharing-functionalities because I want to be able to create a config object (mostly glob paths and environmental options) that I can use within the tasks I've created. However I think that means I would have to duplicate a ton of the functionality that is already in gulp-hub in order to keep my tasks in separate files and auto loaded.
Of course there are other options this is just the first solution I thought of because I do think it would be nice to have a plugin like this that does what it's already doing but also allows for custom configuration to be used in our custom tasks. I just want to get some dialogue going to find the best solution to this problem.
Another option would be to load in the configuration option separately in each custom task.
An example of the API consumed from a task if there was a configuration object bound to its context.
Thoughts?