-
Notifications
You must be signed in to change notification settings - Fork 62
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
Prefix is passed only when plugin in manifest is an array #31
Comments
It should do the exact same thing https://github.com/hapijs/glue/blob/master/lib/index.js#L88-L105 |
@AdriVanHoudt see this https://github.com/hapijs/glue/blob/master/lib/index.js#L175-L196 if plugin is not array, also, relevant test case: https://github.com/marinintim/glue/blob/master/test/index.js#L182 |
ah yes that is it I think |
@AdriVanHoudt as far as I can see, if obj is inside array, then it's treated as register options, otherwise as plugin options. I'm trying straightforward hack, but tests are failing at So, I see two solutions:
|
@csrl: I would be glad to pull request any of these options |
the solution is up to @csrl |
Yep, this aspect of the glue manifest has always bothered me, but I've been trying not to break manifest (major version) compatibility. I'm open to suggestions/approaches. |
Perhaps with the Hapi 10 + Node 4, it might be a good time to revisit the manifest structure and break some things. |
But what's the point to pass plugins as object with single key in array, to support multiple instances of the same plugin? |
Prior to 2.1.0 the 'plugins' only understood an object whose key's were the plugin to load. In order to support loading multiple instances of the same plugin, the object keys' values could be an array of objects or an object. It was also the only way to provide registerOptions for the plugin as well. If the value was an object, then the object was treated as the pluginOptions, and no registerOptions could be specified. pre 2.1.0 configuration options:Only supports a single plugin instance, no registerOptions options available: plugins: {
'./app/api': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}
// equivalent api call
server.register(
{
register: require('./app/api'),
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
{},
callback
); Load single instance of the plugin. registerOptions available, pluginOptions must be in 'options' sub object: // same as above, but using multi instance plugin syntax
plugins: {
'./app/api': [{
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}]
} // and adding registerOptions into the mix
plugins: {
'./app/api': [
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
'options': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}
]
}
// equivalent api call
server.register(
{
register: require('./app/api'),
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
},
callback
); Load multiple instances of the plugin. registerOptions available, pluginOptions must be in 'options' sub object: plugins: {
'./app/api': [
// instance 1
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
'options': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
// instance 2
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
'options': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}
]
}
// equivalent api calls
server.register(
{
register: require('./app/api'),
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
},
callback
);
server.register(
{
register: require('./app/api'),
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
},
callback
); A possible v2.1.0 configuration equivalent of the above:plugins: [
// instance 1
{'./app/api': [{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}]},
// instance 2
{'./app/api': [{
registerOption1: 'regValue1',
registerOption2: 'regValue2'
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
}},
]
// same api calls as previous example // And we can also do multi-instance without registerOptions and the extra syntax
plugins: [
// instance 1
{'./app/api': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}},
// instance 2
{'./app/api': {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}},
] I propose the following configuration syntaxto keep it very close to the server.register API: registrations: [
{
plugin: './app/api',
options: {
registerOption1: 'regValue1',
registerOption2: 'regValue2'
}
}
]
// and also
registrations: [
{
plugin: {
register: './app/api',
options: {
pluginOption1: 'pluginValue1',
pluginOption2: 'pluginValue2'
}
},
options: {
registerOption1: 'regValue1',
registerOption2: 'regValue2'
}
}
] |
👍 for this change, I tripped over because of this one, too. Also, I found having the plugin path as a key a bit cumbersome, liking the change to make it a value instead. The more explicit the registration API the better, and following conventions of existing package is obviously a plus as well. |
FYI @lloydbenson these changes are upcoming if you want to get rejoice ready for them. |
I've implemented this on 'v3' branch. I'll merge to master after I get some feedback. |
@harriha @devinivy @marinintim @AdriVanHoudt I'm interested in you all testing the v3 branch out and seeing if it meets your needs. Please provide feedback on the docs as well. |
I currently do not use glue and time is a bit scarce and that one commit is too big to quickly review but I like the new format, also you made the |
I think this looks good. One very small note is that I see hapi stylized as "Hapi" in the docs. My understanding is that it's typically written in lowercase. The manifest format is nice, as long as you don't get the two separate (registration versus plugin) option fields mixed-up. I don't think it's a problem, though, really. This will be sufficient to implement plugin dependency ordering, whether as part of v3 or possibly v3.1. |
Looks good to me. Commit looks good too, but didn't tested though (maybe on weekend) |
@AdriVanHoudt vs using an async library or such? but, yah, not so clean to call everything directly with error handling. @devinivy thanks I'll get the casing cleaned up. I also went back and forth on the registration versus plugin. I decided to stick with mapping the hapi API function names (eg. register) |
@csrl mostly styling but it is fine since it proves your point :P |
@AdriVanHoudt ok. I also intend it to be descriptive of the manifest entries mapping to the API calls, so I was overly verbose in order to do so. |
Did this land? I'm not sure it's working as expected (or alternatively, I misunderstood something). // success
{
registrations: [
{
plugin: './path/to/plugin',
options: {
routes: {
prefix: '/api'
}
}
}
]
}
// failure
{
registrations: [
{
plugin: {
register: './path/to/plugin',
options: {
routes: {
prefix: '/api'
}
}
}
}
]
} |
That is as expected. The second form, you are passing what should be registration options as plugin options, which is incorrect. |
Is it possible to pass options and the prefix? Or do I just append the routes in my file? I using Hapi v16.2
|
I believe the problem is that your {
registrations: [
{
plugin: {
register: './path/to/plugin',
options: {
value: 'some val'
}
},
routes: {
prefix: '/api'
}
}
]
} |
Thanks for the prompt reply. I just had duplicating work.
server.route(routes.map(internals.prefix_routes)); |
Oh, I'm sorry I left out a piece in my last example I think. Try this {
registrations: [
{
plugin: {
register: './path/to/plugin',
options: {
value: 'some val'
}
},
options: {
routes: {
prefix: '/api'
}
}
}
]
} (I set |
Thanks, |
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. |
If in manifest I do:
routes in
./app/api
are registered without prefix.But if I wrap in array, it does the right thing.
Needs clarifying the docs or fix to support both variants.
The text was updated successfully, but these errors were encountered: