From 30c40523fa3d2407d0eaf3ebb567f5562a1e948e Mon Sep 17 00:00:00 2001 From: Patrik Oldsberg Date: Sun, 25 Jan 2026 12:19:31 +0100 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Patrik Oldsberg --- .changeset/module-handle-api.md | 2 +- docs/backend-system/architecture/05-extension-points.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.changeset/module-handle-api.md b/.changeset/module-handle-api.md index 376b1774de..28b0134ec1 100644 --- a/.changeset/module-handle-api.md +++ b/.changeset/module-handle-api.md @@ -2,4 +2,4 @@ '@backstage/backend-plugin-api': minor --- -Added support for extension point factories. This makes it possible to call `registerExtensionPoint` with a single options argument and provide an factory for the extension point rather than a direct implementation. The factory is passed a context with a `reportModuleStartupFailure` method that makes it possible for plugins to report and attribute startup errors to the module that consumed the extension point. +Added support for extension point factories. This makes it possible to call `registerExtensionPoint` with a single options argument and provide a factory for the extension point rather than a direct implementation. The factory is passed a context with a `reportModuleStartupFailure` method that makes it possible for plugins to report and attribute startup errors to the module that consumed the extension point. diff --git a/docs/backend-system/architecture/05-extension-points.md b/docs/backend-system/architecture/05-extension-points.md index c9c03e7c08..611807020e 100644 --- a/docs/backend-system/architecture/05-extension-points.md +++ b/docs/backend-system/architecture/05-extension-points.md @@ -67,7 +67,7 @@ Note that we create a closure that adds to a shared `actions` structure when `ad ## Factory-Based Extension Points -In some cases, you may want to be able to attribute startup failures to modules that provided an extension, rather than failing the plugin startup entirely. To do this, you can use a variant of `registerExtensionPoint` that instead of providing a direct implementation, registers a factory function that produces the implementation. This factory receives a `ExtensionPointFactoryContext` with a `reportModuleStartupFailure` method that lets you report startup failures and attribute them to the module. +In some cases, you may want to be able to attribute startup failures to modules that provided an extension, rather than failing the plugin startup entirely. To do this, you can use a variant of `registerExtensionPoint` that instead of providing a direct implementation, registers a factory function that produces the implementation. This factory receives an `ExtensionPointFactoryContext` with a `reportModuleStartupFailure` method that lets you report startup failures and attribute them to the module. Here's an example of registering an extension point using a factory: