avvio
avvio copied to clipboard
`start()` is not exported on instance
🐛 Bug Report
.start()
is not exported on instance
, however, .ready()
is.
To Reproduce
Steps to reproduce the behavior:
const app = {};
const avvioOptions = {
expose: {
use: 'load'
}
};
require('avvio')(app, avvioOptions);
console.log(app.load === undefined); // false
console.log(app.ready === undefined); // false
console.log(app.start === undefined); // true
Expected behavior
I expect that start
is exported either automatically or via the expose
configuration option in boot.js at line 18: startKey = expose.start || 'start'
const app = {};
const avvioOptions = {
expose: {
use: 'load'
}
};
require('avvio')(app, avvioOptions);
console.log(app.load === undefined); // false
console.log(app.ready === undefined); // false
console.log(app.start === undefined); // false
// --------- and/or ------
const app = {};
const avvioOptions = {
expose: {
start: 'blastOff'
}
};
require('avvio')(app, avvioOptions);
console.log(app.blastOff === undefined); // false
Your Environment
- node version: 12
- fastify version: N/A avvio = 7.0.3
- os: Mac
Hello! Why you need to access start
?
It is basically an internal API, and calling ready
automatically calls start
behind the scenes.
@delvedor: Thanks for the quick reply! Why? I read advanced usage examples in the tests and tried to match that usage. 😅
I do have a PR for this with tests, but, I stopped when I saw how things were exposed under the hood and wanted to understand your intent. If the intent is that autostart: false
is not usable without saving a reference to return value ofavvio()
, then start
not being exposed is not a bug.
Depending on how one initializes avvio
some (apparently internal) methods on the Boot prototype that are required for usage with { autostart: false }
are not exposed [see above]. The presence of this option in the documentations makes it sound like start()
is public, since it can/must be manually called by the user.
I think clarification in the docs on how to use autostart: false
and what order onClose
handlers** are executed in would be helpful :+1:.
** This is the original reason that I was poking around in the tests :)