Mount directories containing your routes, etc. into your hapi server
This module will allow you to organize your handlers as such:
- server/
- ext/
- on-post-auth.js
- methods/
- get-user.js
- routes/
- user/
- get.js
- post.js
A single object of the array overloads for server.ext
, server.method
, and server.route
must be exported. An array can also be used, this module will flatten the array anyway.
For the ext
and methods
directories, this will require
all .js files inside them.
For the routes
directory, only valid HTTP verbs in lowercase (get.js
, post.js
, etc.) are included.
Example (just to give you an idea how modular your server will be now):
ext/on-post-auth.js
module.exports = {
type: 'onPostAuth',
async method(request, h) {
// ...
}
}
methods/get-user.js
module.exports = {
name: 'getUsers',
async method() {
// ...
}
}
routes/user/get.js
module.exports = {
path: '/user',
method: 'GET',
async handler(request, h) {
// ...
}
}
Note: Modules with empty exports will be excluded. This is to avoid errors in development, e.g. when creating a new blank file. (Hapi will emit an error anyway for these files since they don't match the schema.) Modules that export null
or undefined
will also be excluded.
await server.register(
{
plugin: require('hapi-mount'),
options: {
/* cwd, routes, methods, ext */
}
},
options
)
cwd: string
: Main server directory to look forroutes
,methods
, andext
. Default:"."
. This is resolved against the current working directory.routes: string
: Name of the routes directory. Default:"routes"
.methods: string
: Name of the methods directory. Default:"methods"
.ext: string
: Name of the directory for extension functions. Default:"ext"
bind: object
: Object to bind as the context. (Plugin binds are isolated.) Optional.bindParentContext: boolean
: Bind to the context of the parent realm.
If the route object is a function, it will be transformed into the handler (handler
) for the route.
If you use the format described above for specifying routes, the path
and method
will default to the path dirname
and basename
, respectively. For example, a file at foo/bar/get.js
will default all of its exported objects with { path: '/foo/bar', method: 'get' }
.
If the ext object is a function, it will be transformed into the method
property for the ext object.
If you use the kebab case version of a valid Hapi extension point as the filename, the type
will default to that extension point. For example, a file at on-pre-response.js
will default to { type: 'onPreResponse' }
.
If the method object is a function, it will be transformed into the method
property for the method object.
If you don't specify the name
for the method, the name will default to the camel case version of the basename of the file. For example, a file at get-database.js
will default to { name: 'getDatabase' }
If this behavior isn't your style, simply specify everything in the schema.
<=4
- hapi v16 compatible>=5
- hapi v17 compatible
Oops. Looks like modules of this kind have been done already. Here they are for reference:
- hapi-methods-injection (Not quite sure here.)
- hapi-router (We definitely have more features than them now.)