docs/releases/v1.30.0-next.3-changelog.md
Upgrade Helper: https://backstage.github.io/upgrade-helper/?to=1.30.0-next.3
7c5f3b0: The createServiceRef function now accepts a new boolean multiple option. The multiple option defaults to false and when set to true, it enables that multiple implementation are installed for the created service ref.
We're looking for ways to make it possible to augment services without the need to replace the entire service.
Typical example of that being the ability to install support for additional targets for the UrlReader service without replacing the service itself. This achieves that by allowing us to define services that can have multiple simultaneous implementation, allowing the UrlReader implementation to depend on such a service to collect all possible implementation of support for external targets:
// @backstage/backend-defaults
+ export const urlReaderFactoriesServiceRef = createServiceRef<ReaderFactory>({
+ id: 'core.urlReader.factories',
+ scope: 'plugin',
+ multiton: true,
+ });
...
export const urlReaderServiceFactory = createServiceFactory({
service: coreServices.urlReader,
deps: {
config: coreServices.rootConfig,
logger: coreServices.logger,
+ factories: urlReaderFactoriesServiceRef,
},
- async factory({ config, logger }) {
+ async factory({ config, logger, factories }) {
return UrlReaders.default({
config,
logger,
+ factories,
});
},
});
With that, you can then add more custom UrlReader factories by installing more implementations of the urlReaderFactoriesServiceRef in your backend instance. Something like:
// packages/backend/index.ts
import { createServiceFactory } from '@backstage/backend-plugin-api';
import { urlReaderFactoriesServiceRef } from '@backstage/backend-defaults';
...
backend.add(createServiceFactory({
service: urlReaderFactoriesServiceRef,
deps: {},
async factory() {
return CustomUrlReader.factory;
},
}));
...
6061061: Added createBackendFeatureLoader, which can be used to create an installable backend feature that can in turn load in additional backend features in a dynamic way.
ba9abf4: The SchedulerService now allows tasks with frequency: { trigger: 'manual' }. This means that the task will not be scheduled, but rather run only when manually triggered with SchedulerService.triggerTask.
8b13183: Added createBackendFeatureLoader, which can be used to programmatically select and install backend features.
A feature loader can return an list of features to be installed, for example in the form on an Array or other for of iterable, which allows for the loader to be defined as a generator function. Both synchronous and asynchronous loaders are supported.
Additionally, a loader can depend on services in its implementation, with the restriction that it can only depend on root-scoped services, and it may not override services that have already been instantiated.
const searchLoader = createBackendFeatureLoader({
deps: {
config: coreServices.rootConfig,
},
*loader({ config }) {
// Example of a custom config flag to enable search
if (config.getOptionalString('customFeatureToggle.search')) {
yield import('@backstage/plugin-search-backend/alpha');
yield import('@backstage/plugin-search-backend-module-catalog/alpha');
yield import('@backstage/plugin-search-backend-module-explore/alpha');
yield import('@backstage/plugin-search-backend-module-techdocs/alpha');
}
},
});
Updated dependencies
72754db: BREAKING: All types of route refs are always considered optional by useRouteRef, which means the caller must always handle a potential undefined return value. Related to this change, the optional option from createExternalRouteRef has been removed, since it is no longer necessary.
This is released as an immediate breaking change as we expect the usage of the new route refs to be extremely low or zero, since plugins that support the new system will still use route refs and useRouteRef from @backstage/core-plugin-api in combination with convertLegacyRouteRef from @backstage/core-compat-api.
params in other properties of the createExtensionBlueprint options by providing a callback..signIn.resolvers now take precedence over sign-in resolvers passed to signInResolver option of createOAuthProviderFactory. This effectively makes sign-in resolvers passed via the signInResolver the default one, which you can then override through configuration./alpha now have more accurate and granular default filters.RepoBranchPicker that supports autocompletion for BitbucketBackendFeatures from @backstage/backend-plugin-api, including feature loaders.ServiceRegister implementation to enable registering multiple service implementations for a given service ref.packages options to config schemaSchedulerService now allows tasks with frequency: { trigger: 'manual' }. This means that the task will not be scheduled, but rather run only when manually triggered with SchedulerService.triggerTask.UrlReader service to depends on multiple instances of UrlReaderFactoryProvider service.PluginTaskScheduler now allows tasks with frequency: { trigger: 'manual' }. This means that the task will not be scheduled, but rather run only when manually triggered with PluginTaskScheduler.triggerTask.BackendFeautures from @backstage/backend-plugin-api.ServiceFactoryTester to be able to test services that enables multi implementation installation.useRouteRef, which can now always return undefined.compatWrapper and convertLegacyRouteRef now support converting from the new system to the old.useRouteRef, which can now always return undefined.useRouteRef, which can now always return undefined.@graphiql/react to ^0.23.0.useRouteRef, which can now always return undefined.listBranchesByRepository to BitbucketCloudClientsingle or multiple implementations./alpha exports will now be enabled by default.kubernetes.clusterLocatorMethods[].clusters[].customResources to the configuration schema.
This was already documented and supported by the plugin.branchesDefaultTableOutputs where output elements overlapped on smaller screen sizesisJsonObject utility function for scaffolder review state componentsingle or multiple implementations.mkdocs-redirects plugin. Redirects defined using the mkdocs-redirect plugin will be handled automatically in TechDocs. Redirecting to external urls is not supported. In the case that an external redirect url is provided, TechDocs will redirect to the current documentation site home.