You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@loopback/boot when used via BootMixin only provides support for BootOptions a.k.a. conventions. To support a variety of use cases such as generating OpenAPI Spec without starting a server, APIC use cases, etc, we need to provide support for BootExecOptions via the Mixin.
There is some ground work already done with BootExecOptions as part of the initial PR for boot however there needs to be more discussion and consensus around the API design of consuming BootExecOptions from a user perspective, and the options it should support.
The current ExecOptions provides support for binding additional Booters, filtering Booters that are executed during a call to boot and the phases that are executed. We should determine the exact nature of these filters and how they handle scenarios such as a Booter with a given name not being bound, a phase name that doesn't exist. Do we allow arbitrary phases to be created? How can this be leveraged by a Booter, etc.
This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.
@loopback/boot
when used viaBootMixin
only provides support forBootOptions
a.k.a. conventions. To support a variety of use cases such as generating OpenAPI Spec without starting a server, APIC use cases, etc, we need to provide support forBootExecOptions
via the Mixin.There is some ground work already done with
BootExecOptions
as part of the initial PR for boot however there needs to be more discussion and consensus around the API design of consuming BootExecOptions from a user perspective, and the options it should support.The current ExecOptions provides support for binding additional Booters, filtering Booters that are executed during a call to
boot
and thephases
that are executed. We should determine the exact nature of these filters and how they handle scenarios such as aBooter
with a given name not being bound, aphase
name that doesn't exist. Do we allow arbitrary phases to be created? How can this be leveraged by a Booter, etc.Some related discussion can be found in the original PR: #858, #858 (comment), #858 (comment), #858 (review),
The text was updated successfully, but these errors were encountered: