Introduce an extension factory middleware

[iamEAP]

What / Why

I believe we'll find a variety of use-cases unlocked if we introduce a way to modify extensions en-masse as they are being instantiated. A naive example of what would be possible:

const app = createApp({
  features,
  *extensionFactoryMiddleware(originalFactory, context) {
    const output = originalFactory();
    yield* output;
    const element = output.get(coreExtensionData.reactElement);

    const owner = getOwnerForPlugin(context.node.spec.source?.id);

    if (element) {
      // Associate analytics events within this extension to a plugin "owner"
      yield coreExtensionData.reactElement(
        <AnalyticsContext attributes={{ owner }>
          {element}
        </AnalyticsContext>,
      );
    }
  },
});

Another use-case would be swapping out extensions entirely under some circumstances, e.g. for A/B testing (for which access to metadata about the extension tree would be helpful).

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Tests for new functionality and regression tests for bug fixes
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage/frontend-app-api	packages/frontend-app-api	patch	v0.10.6-next.1
@backstage/frontend-defaults	packages/frontend-defaults	patch	v0.1.7-next.1

[Rugvip]

Nice! 🎉

Some optional bits and followup investigation but good to merge for me

[Rugvip]

👌

[Rugvip]

Forgot about this bit and was thinking it could make sense to wrap things up a bit more potentially. Then I had the thought that maybe we should go in the opposite direction, where we only return { apis, tree } here and grab the root from the tree instead. Or going even further, adding apis into the tree and just returning { tree }

Either way, happy to merge as is but I might tinker a bit with this in a followup.

[iamEAP]

Mmm. Could be. Didn't personally feel super comfortable making backwards incompatible changes to this function, but if it makes sense, go for it.

[Rugvip]

The type indicates that that we can override inputs as well right? i.e.

backstage/packages/frontend-plugin-api/src/wiring/createExtension.ts

Lines 407 to 412 in 4c46e99

	config: (innerContext?.config ?? config) as any,
	inputs: resolveInputOverrides(
	options.inputs,
	inputs,
	innerContext?.inputs,
	) as any,

I can take care of getting that sorted if you want though.

[iamEAP]

That'd be great! I think it also can take params? But it wasn't immediately obvious to me how to incorporate either.

[github-actions]

Thank you for contributing to Backstage! The changes in this pull request will be part of the 1.37.0 release, scheduled for Tue, 18 Mar 2025.