-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
dependency as part of plugin attributes #2803
Comments
There already is a Relatedly, I'm working on a module that will reorder a list of plugins so that they load in the correct order based upon the |
I shouldn't open tickets when I'm tired. I'm specifically looking for something that makes sure they're registered first. Your module sounds awesome |
Check here soon: https://github.com/devinivy/hodgepodge |
Any reason to implement it this way as opposed to it being part of core? |
This just isn't the way hapi plugin dependencies are architected, and it would add complexity into hapi core to allow for deferred plugin registration. @hueniverse has been suggesting for a while that tools be created to assist with the bare-bones plugin registration that hapi provides, so maybe that's the direction the community oughtta head if we want to see solutions to plugin-registration woes. |
You are basically asking for the entire register method to be inside an after callback. |
Yes, for now I've been following this pattern : exports.register = function (server, options, next) {
server.dependency(['vision'], internals.register(options));
return next();
};
internals.register = function (options) {
return (server, next) {
// logic
return next();
}
} |
hapi plugin dependency resolution– seems to be ready now: https://github.com/devinivy/hodgepodge . Definitely has some limitations– please give feedback. @danielb2 I used your pattern above as part of an example. |
great timing as my laptop suddenly stopped working and my current work was lost. I'll give feedback soon :) |
Cool plugin @devinivy! Not sure why you added |
I added it so that a plugin can require that it be registered using hodgepodge. If you register it without deleting that attribute, hapi will throw since it's not a valid attribute. Which is intended– you want to guarantee that the attribute is consumed. Edit |
Ah like that I see, was not obvious :P And hmm fair point... thanks for the explanation, didn't think about registering at different times |
@devinivy is it necessary to register the plugin with hodgepodge before being able to use it? The documentation isn't clear, and my setup uses a manifest file in JSON format which is read in using glue with confidence. Hodgepodge would need a solution for that if this is the case. |
The way it works is that you give it a list of plugin registrations as would be passed to Ex. of how to use hodgepodge, var plugins = Hodgepodge([
pluginA, // pluginA.register.attributes.dependencies === 'pluginB'
pluginB
]);
// Now plugins looks like [pluginB, pluginA]
// This ordering respects pluginA's dependency on pluginB
server.register(plugins, function (err) {/* ... */}); Edit |
I think up higher would be good, and it could be shown in For our setups we do all use glue/rejoice because we have so many plugins we have to load. We used to have a big async.waterfall setup, but moved away from that in favor of rejoice. |
Thanks– let me know if the update to the readme is an improvement. Feel free to move this over into an issue on the hodgepodge repo since this issue is closed. Edit Oops– realized it's not closed. |
I am not going to add this to core at this point. It adds significant complexity because the only place where it can perform this sort in a consistent and useful way is in Since this functionality already exists, it is not worth the complexity and edge cases to solve it in core. |
Out of curiosity @hueniverse, do you think a tool like hodgepodge is worthwhile? |
I think if your plugin setup is so complex that you need it, you might want to rethink your mess. It makes sense as part of a bigger tool chain. |
@hueniverse my feelings is that while following the pattern I have is fairly straight forward, it's already more messy than I'd like. Is there a cleaner way that I've missed? @devinivy I think hodgepodge didn't really gain me anything over what I'm doing already unless I can have it working more seemleessly, especially with Glue. IOW, it's just as messy. |
That's the process. Cleaner will require tooling to basically auto generate that code. |
Currently
server.dependency
is used to set package dependency and the callback is necessary in order to define, for example, routes that rely on other plugins.This is a common pattern now that vision is extracted from core.
Could dependencies handled in the plugin attribute make this easier? This would indicate to hapi to not try to load the plugin until dependencies have been met.
The text was updated successfully, but these errors were encountered: