Support inline dependencies on plugins #2405
Conversation
| }; | ||
|
|
||
| Hoek.assert(item.name, 'Missing plugin name', hint); | ||
| Hoek.assert(typeof item.dependencies === 'string' || |
There was a problem hiding this comment.
Why not a joi.assert here?
|
@hueniverse like that or do you want to check the whole item object ? I don't know if doing it now would be a breaking change for some people. |
|
This is fine, but why a breaking change for some people? |
Support inline dependencies on plugins
|
|
||
| selection.dependency(item.dependencies, function (server, next) { | ||
|
|
||
| // Deferred registration when all dependencies are resolve |
There was a problem hiding this comment.
This is a change in behavior. Dependency does not imply order. If you want to dictate order of registration you can't use this mechanism.
There was a problem hiding this comment.
I don't think there's an order to have here, dependencies in registration all just have to be there before the plugin begins his own registration. How is that a change if there wasn't any mechanism for that before ?
EDIT: now I get what you mean, I think people will expect that. If you declare a dependency to register a auth scheme or strategy for example, you need it to be done before you declare your own routes right ? What I did was less surprising IMO.
|
@hueniverse breaking because depending on how we validate the object, we might reject existing configurations if it's too strict. |
|
Sorry about not working on this. Glad it's landed though :-) |
|
@Marsup not if we allow unknown keys :-) |
|
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions. |
Fixes #2332.
I have a small doubt on L248 of this patch,
serveris the same asselectionright ?