Merge branch 'master' into bui-header

# Conflicts:
#	docs-ui/public/theme-backstage.css
#	docs-ui/public/theme-spotify.css
#	packages/ui/.storybook/themes/spotify.css
This commit is contained in:
Charles de Dreuille
2025-08-11 10:11:56 +02:00
431 changed files with 8503 additions and 3986 deletions
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-defaults': patch
---
Deprecated `createPublicSignInApp`, which has been replaced by the new `appModulePublicSignIn` from `@backstage/plugin-app/alpha` instead.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: Remove deprecated `source` property from the `AppNodeSpec` type, use `AppNodeSpec.plugin` instead.
+24
View File
@@ -0,0 +1,24 @@
---
'@backstage/frontend-plugin-api': patch
'@backstage/frontend-app-api': patch
---
Add support for a new `aliasFor` option for `createRouteRef`. This allows for the creation of a new route ref that acts as an alias for an existing route ref that is installed in the app. This is particularly useful when creating modules that override existing plugin pages, without referring to the existing plugin. For example:
```tsx
export default createFrontendModule({
pluginId: 'catalog',
extensions: [
PageBlueprint.make({
params: {
defaultPath: '/catalog',
routeRef: createRouteRef({ aliasFor: 'catalog.catalogIndex' }),
loader: () =>
import('./CustomCatalogIndexPage').then(m => (
<m.CustomCatalogIndexPage />
)),
},
}),
],
});
```
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The `defaultPath` param of `PageBlueprint` has been renamed to `path`. This change does not affect the compatibility of extensions created with older versions of this blueprint.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-app': patch
---
Default implementations of core components are now provided by this package.
+15
View File
@@ -0,0 +1,15 @@
---
'@backstage/plugin-app': minor
---
**BREAKING**: The `componentsApi` implementation has been removed from the plugin and replaced with the new `SwappableComponentsApi` instead.
If you were overriding the `componentsApi` implementation, you can now use the new `SwappableComponentsApi` instead.
```ts
// old
appPlugin.getExtension('api:app/components').override(...)
// new
appPlugin.getExtension('api:app/swappable-components').override(...)
```
@@ -0,0 +1,96 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The component system has been overhauled to use `SwappableComponent` instead of `ComponentRef`. Several APIs have been removed and replaced:
- Removed: `createComponentRef`, `createComponentExtension`, `ComponentRef`, `ComponentsApi`, `componentsApiRef`, `useComponentRef`, `coreComponentRefs`
- Added: `createSwappableComponent`, `SwappableComponentBlueprint`, `SwappableComponentRef`, `SwappableComponentsApi`, `swappableComponentsApiRef`
**BREAKING**: The default `componentRefs` and exported `Core*Props` have been removed and have replacement `SwappableComponents` and revised type names instead.
- The `errorBoundaryFallback` component and `CoreErrorBoundaryFallbackProps` type have been replaced with `ErrorDisplay` swappable component and `CoreErrorDisplayProps` respectively.
- The `progress` component and `CoreProgressProps` type have been replaced with `Progress` swappable component and `ProgressProps` respectively.
- The `notFoundErrorPage` component and `CoreNotFoundErrorPageProps` type have been replaced with `NotFoundErrorPage` swappable component and `NotFoundErrorPageProps` respectively.
**Migration for creating swappable components:**
```tsx
// OLD: Using createComponentRef and createComponentExtension
import {
createComponentRef,
createComponentExtension,
} from '@backstage/frontend-plugin-api';
const myComponentRef = createComponentRef<{ title: string }>({
id: 'my-plugin.my-component',
});
const myComponentExtension = createComponentExtension({
ref: myComponentRef,
loader: {
lazy: () => import('./MyComponent').then(m => m.MyComponent),
},
});
// NEW: Using createSwappableComponent and SwappableComponentBlueprint
import {
createSwappableComponent,
SwappableComponentBlueprint,
} from '@backstage/frontend-plugin-api';
const MySwappableComponent = createSwappableComponent({
id: 'my-plugin.my-component',
loader: () => import('./MyComponent').then(m => m.MyComponent),
});
const myComponentExtension = SwappableComponentBlueprint.make({
name: 'my-component',
params: {
component: MySwappableComponent,
loader: () => import('./MyComponent').then(m => m.MyComponent),
},
});
```
**Migration for using components:**
```tsx
// OLD: Using ComponentsApi and useComponentRef
import {
useComponentRef,
componentsApiRef,
useApi,
coreComponentRefs,
} from '@backstage/frontend-plugin-api';
const MyComponent = useComponentRef(myComponentRef);
const ProgressComponent = useComponentRef(coreComponentRefs.progress);
// NEW: Direct component usage
import { Progress } from '@backstage/frontend-plugin-api';
// Use directly as React Component
<Progress />
<MySwappableComponent title="Hello World" />
```
**Migration for core component references:**
```tsx
// OLD: Core component refs
import { coreComponentRefs } from '@backstage/frontend-plugin-api';
coreComponentRefs.progress
coreComponentRefs.notFoundErrorPage
coreComponentRefs.errorBoundaryFallback
// NEW: Direct swappable component imports
import { Progress, NotFoundErrorPage, ErrorDisplay } from '@backstage/frontend-plugin-api';
// Use directly as React components
<Progress />
<NotFoundErrorPage />
<ErrorDisplay plugin={plugin} error={error} resetError={resetError} />
```
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': minor
---
Added plugin and module templates for the new frontend system. These templates are not included by default, but can be included by adding `@backstage/cli/templates/new-frontend-plugin` and `@backstage/cli/templates/new-frontend-plugin-module` as [custom templates](https://backstage.io/docs/tooling/cli/templates#installing-custom-templates).
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/create-app': patch
---
Bumped create-app version.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-test-utils': patch
---
Updated import of the `FrontendFeature` type.
+21
View File
@@ -0,0 +1,21 @@
---
'@backstage/plugin-catalog-unprocessed-entities': patch
'@backstage/frontend-defaults': patch
'@backstage/core-compat-api': patch
'@backstage/plugin-app-visualizer': patch
'@backstage/plugin-catalog-import': patch
'@backstage/plugin-catalog-graph': patch
'@backstage/plugin-notifications': patch
'@backstage/plugin-user-settings': patch
'@backstage/plugin-search-react': patch
'@backstage/plugin-kubernetes': patch
'@backstage/plugin-scaffolder': patch
'@backstage/plugin-api-docs': patch
'@backstage/plugin-devtools': patch
'@backstage/plugin-techdocs': patch
'@backstage/plugin-catalog': patch
'@backstage/plugin-search': patch
'@backstage/plugin-home': patch
---
Internal update to align with new blueprint parameter naming in the new frontend system.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend': patch
---
Attempt to circumvent event listener memory leak in compression middleware
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: Removed the deprecated `createFrontendPlugin` variant where the plugin ID is passed via an `id` option. To update existing code, switch to using the `pluginId` option instead.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: Removed the `routable` property from `ExtensionBoundary`. This property was never needed in practice and is instead inferred from whether or not the extension outputs a route reference. It can be safely removed.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The `ResolveInputValueOverrides` type is no longer exported.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: Removed the ability to define a default extension `name` in blueprints. This option had no practical purpose as blueprints already use the `kind` to identity the source of the extension.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-app': patch
---
Added a new module for implementing public sign-in apps, exported as `appModulePublicSignIn` via the `/alpha` sub-path export. This replaces the `createPublicSignInApp` export from `@backstage/frontend-defaults`, which is now deprecated.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-app-api': minor
---
**BREAKING**: Removed the deprecated `FrontendFeature` type, import it from `@backstage/frontend-plugin-api` instead.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-defaults': minor
---
**BREAKING**: Removed the deprecated `CreateAppFeatureLoader` and support for it in other APIs. Switch existing usage to use the newer `createFrontendFeatureLoader` from `@backstage/frontend-plugin-api` instead.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The separate `RouteResolutionApiResolveOptions` type has been removed.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-compat-api': minor
---
**BREAKING**: The `componentsApi` implementation has been removed from the plugin and replaced with the new `SwappableComponentsApi` instead. Which means that the `componentsApi` is not longer backwards compatible with legacy plugins.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend': minor
---
Fixed fs:readdir action example
+39
View File
@@ -0,0 +1,39 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: In an attempt to align some of the API's around providing components to `Blueprints`, we've renamed the parameters for both the `RouterBlueprint` and `AppRootWrapperBlueprint` from `Component` to `component`.
```tsx
// old
RouterBlueprint.make({
params: {
Component: ({ children }) => <div>{children}</div>,
},
});
// new
RouterBlueprint.make({
params: {
component: ({ children }) => <div>{children}</div>,
},
});
```
```tsx
// old
AppRootWrapperBlueprint.make({
params: {
Component: ({ children }) => <div>{children}</div>,
},
});
// new
AppRootWrapperBlueprint.make({
params: {
component: ({ children }) => <div>{children}</div>,
},
});
```
As part of this change, the type for `component` has also changed from `ComponentType<PropsWithChildren<{}>>` to `(props: { children: ReactNode }) => JSX.Element | null` which is not breaking, just a little more reflective of the actual expected component.
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/frontend-test-utils': patch
'@backstage/core-compat-api': patch
'@backstage/plugin-app': patch
---
Updated the usage of the `RouterBlueprint` and `AppRootWrapperBlueprint` to use the lowercase `component` parameter
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-app': minor
---
**BREAKING**: The `app-root-element` extension now only accepts `JSX.Element` in its `element` param, meaning overrides need to be updated.
+12
View File
@@ -0,0 +1,12 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The `AnyRoutes` and `AnyExternalRoutes` types have been removed and their usage has been inlined instead.
Existing usage can be replaced according to their previous definitions:
```ts
type AnyRoutes = { [name in string]: RouteRef | SubRouteRef };
type AnyExternalRoutes = { [name in string]: ExternalRouteRef };
```
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-proxy-backend': patch
---
correct rewrite rule to avoid extra subpath in proxy path
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-app-api': patch
---
Renaming the `getNodesByRoutePath` parameter from `sourcePath` to `routePath`
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-compat-api': minor
---
**BREAKING**: The `defaultPath` override of `convertLegacyPageExtension` has been renamed to `path`, in order to align with the same update that was made to the `PageBlueprint`.
+18
View File
@@ -0,0 +1,18 @@
---
'@backstage/frontend-plugin-api': patch
---
Plugins should now use the new `AnalyticsImplementationBlueprint` to define and provide concrete analytics implementations. For example:
```ts
import { AnalyticsImplementationBlueprint } from '@backstage/frontend-plugin-api';
const AcmeAnalytics = AnalyticsImplementationBlueprint.make({
name: 'acme-analytics',
params: define =>
define({
deps: { config: configApiRef },
factory: ({ config }) => AcmeAnalyticsImpl.fromConfig(config),
}),
});
```
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-app': patch
---
The default implementation of the Analytics API now collects and instantiates analytics implementations exposed via `AnalyticsImplementationBlueprint` extensions. If no such extensions are discovered, the API continues to do nothing with analytics events fired within Backstage. If multiple such extensions are discovered, every discovered implementation automatically receives analytics events.
+3 -3
View File
@@ -4,7 +4,7 @@
**BREAKING**: The `ApiBlueprint` has been updated to use the new advanced type parameters through the new `defineParams` blueprint option. This is an immediate breaking change that requires all existing usages of `ApiBlueprint` to switch to the new callback format. Existing extensions created with the old format are still compatible with the latest version of the plugin API however, meaning that this does not break existing plugins.
To update existing usages of `ApiBlueprint`, you remove the outer level of the `params` object and replace `createApiFactory(...)` with `define => define(...)`.
To update existing usages of `ApiBlueprint`, you remove the outer level of the `params` object and replace `createApiFactory(...)` with `defineParams => defineParams(...)`.
For example, the following old usage:
@@ -28,8 +28,8 @@ is migrated to the following:
```ts
ApiBlueprint.make({
name: 'error',
params: define =>
define({
params: defineParams =>
defineParams({
api: errorApiRef,
deps: { alertApi: alertApiRef },
factory: ({ alertApi }) => {
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/plugin-catalog-graph': patch
'@backstage/plugin-api-docs': patch
'@backstage/plugin-org': patch
---
Updated README instructions for the new frontend system
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': patch
---
Tweaked the return types from `createExtension` and `createExtensionBlueprint` to avoid the forwarding of `ConfigurableExtensionDataRef` into exported types.
+33
View File
@@ -209,41 +209,74 @@
"blue-apples-pump",
"bright-elephants-sparkle",
"calm-geese-serve",
"chatty-coats-sin",
"chatty-dodos-design",
"chatty-schools-post",
"clean-chairs-sit-2",
"clean-chairs-sit",
"clever-plants-warn",
"cold-heads-arrive",
"common-heads-build",
"crazy-pants-exist",
"create-app-1753196727",
"create-app-1754401469",
"cruel-bars-buy",
"cruel-zoos-argue",
"eleven-tigers-drop",
"every-schools-find",
"evil-forks-hang",
"evil-phones-unite",
"fancy-ducks-help",
"fifty-ads-dance",
"five-ducks-hide",
"floppy-groups-hug",
"four-spiders-jump",
"free-months-share",
"fruity-rockets-rhyme",
"full-streets-take",
"funny-brooms-trade",
"funny-dancers-start",
"fuzzy-ducks-speak",
"great-snakes-dress",
"green-lies-invite copy",
"green-lies-invite",
"honest-seas-repeat",
"hot-clowns-behave",
"huge-heads-occur",
"huge-paws-design",
"itchy-doodles-boil",
"little-bugs-care",
"long-grapes-glow",
"lovely-fans-write",
"major-comics-stay",
"mighty-cycles-stay",
"mira-looking-ostrich",
"nej-inte-ostrich",
"nice-actors-cheer",
"nice-buttons-return",
"nice-crabs-clean",
"odd-beans-sell",
"open-seas-ring",
"orange-teams-smell",
"polite-trains-notice",
"quiet-parks-cheer",
"rich-seals-itch",
"ripe-comics-sip",
"sad-cities-lay",
"seven-crabs-stick",
"sixty-clowns-float",
"small-trams-do",
"smart-planes-march",
"spotty-clowns-lose",
"spotty-icons-shake",
"tender-crabs-stay",
"thick-breads-add",
"thirty-dingos-allow",
"thirty-jobs-cut",
"tired-lamps-start",
"twenty-pumas-brush",
"violet-weeks-trade",
"whole-hands-cut",
"wild-apes-care",
"yellow-ducks-burn"
]
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/ui': patch
---
Remove stylesheet import from Select component.
+2 -2
View File
@@ -32,11 +32,11 @@ Usage of the above example looks as follows:
```ts
const example = ExampleBlueprint.make({
params: define => define({
params: defineParams => defineParams({
component: ...,
fetcher: ...,
}),
});
```
This `define => define(<params>)` is also known as the "callback syntax" and is required if a blueprint is created with the new `defineParams` option. The callback syntax can also optionally be used for other blueprints too, which means that it is not a breaking change to remove the `defineParams` option, as long as the external parameter types remain compatible.
This `defineParams => defineParams(<params>)` is also known as the "callback syntax" and is required if a blueprint is created with the new `defineParams` option. The callback syntax can also optionally be used for other blueprints too, which means that it is not a breaking change to remove the `defineParams` option, as long as the external parameter types remain compatible.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-components': patch
---
Updated dependency `linkifyjs` to `4.3.2`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-auth-backend-module-okta-provider': patch
---
Updated dependency `@davidzemon/passport-okta-oauth` to `^0.0.7`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': patch
---
Updated the recommended naming of the blueprint param callback from `define` to `defineParams`, making the syntax `defineParams => defineParams(...)`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': patch
---
Added added defaults for all type parameters of `ExtensionDataRef` and deprecated `AnyExtensionDataRef`, as it is now redundant.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/repo-tools': patch
---
Removed build-in ignore of the `packages/canon` package for knip reports.
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/frontend-plugin-api': patch
'@backstage/plugin-app': patch
---
Adjusted the dialog API types to have more sensible defaults
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/ui': patch
---
Add `startCollapsed` prop on the `SearchField` component in BUI.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-react': minor
---
**BREAKING ALPHA**: The `defaultPath`, `defaultTitle`, and `defaultGroup` params of `PageBlueprint` has been renamed to `path`, `title`, and `group`. The `convertLegacyEntityContentExtension` utility has also received the same change. This change does not affect the compatibility of extensions created with older versions of this blueprint.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The `element` param for `AppRootElementBlueprint` no longer accepts a component. If you are currently passing a component such as `element: () => <MyComponent />` or `element: MyComponent`, simply switch to `element: <MyComponent />`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-search-backend-module-catalog': patch
---
Allow filter to be an array in config schema
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/frontend-defaults': patch
'@backstage/frontend-app-api': patch
'@backstage/cli': patch
---
Deprecated new frontend system config setting `app.experimental.packages` to just `app.packages`. The old config will continue working for the time being, but may be removed in a future release.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-app-api': patch
---
Added a default implementation of the `SwappableComponentsApi` and removing the legacy `ComponentsApi` implementation
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/create-app': patch
---
Updated the `app.packages` config setting now that it no longer is experimental
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/frontend-plugin-api': patch
'@backstage/frontend-app-api': patch
---
Improved runtime error message clarity when extension factories don't return an iterable object.
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/plugin-signals': patch
'@backstage/plugin-home': patch
---
**BREAKING ALPHA**: The `app-root-element` extension now only accepts `JSX.Element` in its `element` param, meaning overrides need to be updated.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-components': patch
---
Added `FavoriteToggleProps`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
The Node.js transform in `@backstage/cli/config/nodeTransformHooks.mjs` now supports the built-in type stripping in Node.js, which is enabled by default from v22.18.0.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-app-api': patch
---
Moved `createSpecializedApp` options to a new `CreateSpecializedAppOptions` type.
+23
View File
@@ -0,0 +1,23 @@
---
'@backstage/frontend-defaults': minor
'@backstage/frontend-app-api': minor
---
**BREAKING**: Restructured some of option fields of `createApp` and `createSpecializedApp`.
- For `createApp`, all option fields _except_ `features` and `bindRoutes` have been moved into a new `advanced` object field.
- For `createSpecializedApp`, all option fields _except_ `features`, `config`, and `bindRoutes` have been moved into a new `advanced` object field.
This helps highlight that some options are meant to rarely be needed or used, and simplifies the usage of those options that are almost always required.
As an example, if you used to supply a custom config loader, you would update your code as follows:
```diff
createApp({
features: [...],
- configLoader: new MyCustomLoader(),
+ advanced: {
+ configLoader: new MyCustomLoader(),
+ },
})
```
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': patch
---
Added inline documentation for `createExtension`, `createExtensionBlueprint`, `createFrontendPlugin`, and `createFrontendModule`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': minor
---
**BREAKING**: The `CommonAnalyticsContext` has been removed, and inlined into `AnalyticsContextValue` instead.
-1
View File
@@ -28,7 +28,6 @@ yarn.lock @backstage/maintainers @backst
/microsite/static @backstage/maintainers @backstage/documentation-maintainers
/packages @backstage/framework-maintainers
/packages/backend-openapi-utils @backstage/maintainers @backstage/reviewers @backstage/openapi-tooling-maintainers
/packages/canon @backstage/design-system-maintainers
/packages/catalog-client @backstage/catalog-maintainers
/packages/catalog-model @backstage/catalog-maintainers
/packages/cli @backstage/tooling-maintainers
@@ -324,6 +324,8 @@ pagerduty
pageview
Pandey
parallelization
param
params
parseable
Patrik
pattison
@@ -378,6 +380,7 @@ replicasets
repo
Repo
repos
requestors
rerender
rerenders
resourcequotas
@@ -385,6 +388,9 @@ retryable
reusability
Reusability
roadmaps
rollbar
rollout
rollouts
Roboto
rollbar
Rollbar
@@ -461,6 +467,7 @@ Superfences
superset
supertype
SVGs
swappable
talkdesk
Talkdesk
Tanzu
-4
View File
@@ -127,10 +127,6 @@ jobs:
- name: build all packages
run: yarn backstage-cli repo build --all
# For now canon has a custom build script and needs to be built separately
- name: build canon
run: yarn --cwd packages/canon build
# For now BUI has a custom build script and needs to be built separately
- name: build BUI
run: yarn --cwd packages/ui build
-4
View File
@@ -110,10 +110,6 @@ jobs:
- name: build
run: yarn backstage-cli repo build --all
# For now canon has a custom build script and needs to be built separately
- name: build canon
run: yarn --cwd packages/canon build
# For now BUI has a custom build script and needs to be built separately
- name: build BUI
run: yarn --cwd packages/ui build
+2 -2
View File
@@ -39,7 +39,7 @@ jobs:
persist-credentials: false
- name: 'Run analysis'
uses: ossf/scorecard-action@dc50aa9510b46c811795eb24b2f1ba02a914e534 # v2.3.3
uses: ossf/scorecard-action@05b42c624433fc40578a4040d5cf5e36ddca8cde # v2.4.2
with:
results_file: results.sarif
results_format: sarif
@@ -67,6 +67,6 @@ jobs:
# Upload the results to GitHub's code scanning dashboard.
- name: 'Upload to code-scanning'
uses: github/codeql-action/upload-sarif@60168efe1c415ce0f5521ea06d5c2062adbeed1b # v3.28.17
uses: github/codeql-action/upload-sarif@51f77329afa6477de8c49fc9c7046c15b9a4e79d # v3.29.5
with:
sarif_file: results.sarif
+4 -4
View File
@@ -1,4 +1,4 @@
name: Sync Canon Docs
name: Sync BUI Docs
on:
push:
branches: [master]
@@ -36,7 +36,7 @@ jobs:
- name: Configure Git
run: |
git config --global user.email noreply@backstage.io
git config --global user.name 'Github Canon Docs workflow'
git config --global user.name 'Github BUI Docs workflow'
- name: Install dependencies
working-directory: docs-ui
@@ -53,9 +53,9 @@ jobs:
git rm -rf .
cp -R ../docs-ui/dist/. .
- name: Commit to canon-storybook repo
- name: Commit to bui-storybook repo
working-directory: bui-external-docs
run: |
git add .
git commit -am "Canon Docs build for backstage/backstage@${{ github.sha }}"
git commit -am "BUI Docs build for backstage/backstage@${{ github.sha }}"
git push
@@ -29,7 +29,7 @@ jobs:
cache-prefix: ${{ runner.os }}-v20.x
- name: Create Snyk report
uses: snyk/actions/node@cdb760004ba9ea4d525f2e043745dfe85bb9077e # master
uses: snyk/actions/node@77490d94e966421e076e95ad8fa87aa55e5ca409 # master
continue-on-error: true # Snyk CLI exits with error when vulnerabilities are found
with:
args: >
+3 -3
View File
@@ -31,7 +31,7 @@ jobs:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- name: Monitor and Synchronize Snyk Policies
uses: snyk/actions/node@cdb760004ba9ea4d525f2e043745dfe85bb9077e # master
uses: snyk/actions/node@77490d94e966421e076e95ad8fa87aa55e5ca409 # master
with:
command: monitor
args: >
@@ -46,7 +46,7 @@ jobs:
# Above we run the `monitor` command, this runs the `test` command which is
# the one that generates the SARIF report that we can upload to GitHub.
- name: Create Snyk report
uses: snyk/actions/node@cdb760004ba9ea4d525f2e043745dfe85bb9077e # master
uses: snyk/actions/node@77490d94e966421e076e95ad8fa87aa55e5ca409 # master
continue-on-error: true # To make sure that SARIF upload gets called
with:
args: >
@@ -58,6 +58,6 @@ jobs:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
NODE_OPTIONS: --max-old-space-size=7168
- name: Upload Snyk report
uses: github/codeql-action/upload-sarif@60168efe1c415ce0f5521ea06d5c2062adbeed1b # v3.28.17
uses: github/codeql-action/upload-sarif@51f77329afa6477de8c49fc9c7046c15b9a4e79d # v3.29.5
with:
sarif_file: snyk.sarif
+3 -3
View File
@@ -55,7 +55,7 @@ jobs:
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@60168efe1c415ce0f5521ea06d5c2062adbeed1b # v3.28.17
uses: github/codeql-action/init@51f77329afa6477de8c49fc9c7046c15b9a4e79d # v3.29.5
with:
languages: ${{ matrix.language }}
# If you wish to specify custom queries, you can do so here or in a config file.
@@ -66,7 +66,7 @@ jobs:
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name: Autobuild
uses: github/codeql-action/autobuild@60168efe1c415ce0f5521ea06d5c2062adbeed1b # v3.28.17
uses: github/codeql-action/autobuild@51f77329afa6477de8c49fc9c7046c15b9a4e79d # v3.29.5
# ️ Command-line programs to run using the OS shell.
# 📚 https://git.io/JvXDl
@@ -80,4 +80,4 @@ jobs:
# make release
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@60168efe1c415ce0f5521ea06d5c2062adbeed1b # v3.28.17
uses: github/codeql-action/analyze@51f77329afa6477de8c49fc9c7046c15b9a4e79d # v3.29.5
+1 -1
View File
@@ -40,7 +40,7 @@ These labels indicate which part of Backstage an issue or pull request relates t
- `area:auditor` - Auditor service and it's use in plugins.
- `area:auth` - Authentication and 3rd party authorization.
- `area:catalog` - The Catalog plugin and the Software Catalog model and integrations.
- `area:design-system` - The Canon design system and library.
- `area:design-system` - The Backstage UI design system and library.
- `area:documentation` - Documentation for adopters, users, and developers.
- `area:events` - The Events system and integrations for other plugins.
- `area:framework` - The core Backstage framework.
+1 -2
View File
@@ -1,8 +1,7 @@
app:
title: Backstage Example App
baseUrl: http://localhost:3000
experimental:
packages: all # ✨
packages: all # ✨
#datadogRum:
# clientToken: '123456789'
+6 -6
View File
@@ -12,8 +12,8 @@
"sync:css:watch": "node scripts/sync-css.js --watch"
},
"resolutions": {
"@types/react": "19.1.8",
"@types/react-dom": "19.1.6"
"@types/react": "19.1.9",
"@types/react-dom": "19.1.7"
},
"dependencies": {
"@codemirror/lang-sass": "^6.0.2",
@@ -31,16 +31,16 @@
"next": "15.3.4",
"next-mdx-remote-client": "^2.1.2",
"prop-types": "^15.8.1",
"react": "19.1.0",
"react-dom": "19.1.0",
"react": "19.1.1",
"react-dom": "19.1.1",
"shiki": "^1.26.1",
"storybook": "^8.6.8"
},
"devDependencies": {
"@types/mdx": "^2.0.13",
"@types/node": "^20",
"@types/react": "19.1.8",
"@types/react-dom": "19.1.6",
"@types/react": "19.1.9",
"@types/react-dom": "19.1.7",
"chokidar": "^3.6.0",
"concurrently": "^8.2.2",
"eslint": "^8",
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -7,6 +7,7 @@ import {
searchFieldDefaultSnippet,
searchFieldSizesSnippet,
searchFieldDescriptionSnippet,
searchFieldCollapsibleSnippet,
} from './search-field.props';
import { PageTitle } from '@/components/PageTitle';
import { Theming } from '@/components/Theming';
@@ -59,6 +60,18 @@ Here's a simple SearchField with a description.
code={searchFieldDescriptionSnippet}
/>
### Collapsible
You can make the SearchField collapsible by setting the `startCollapsed` prop to `true`.
<Snippet
align="center"
py={4}
open
preview={<SearchFieldSnippet story="StartCollapsed" />}
code={searchFieldCollapsibleSnippet}
/>
<Theming component="SearchField" />
<ChangelogComponent component="search-field" />
@@ -25,6 +25,10 @@ export const searchFieldPropDefs: Record<string, PropDef> = {
type: 'string',
required: true,
},
startCollapsed: {
type: 'boolean',
default: 'false',
},
...classNamePropDefs,
...stylePropDefs,
};
@@ -41,3 +45,5 @@ export const searchFieldSizesSnippet = `<Flex direction="row" gap="4">
</Flex>`;
export const searchFieldDescriptionSnippet = `<SearchField label="Label" description="Description" placeholder="Enter a URL" />`;
export const searchFieldCollapsibleSnippet = `<SearchField startCollapsed />`;
+49 -49
View File
@@ -1201,21 +1201,21 @@ __metadata:
languageName: node
linkType: hard
"@types/react-dom@npm:19.1.6":
version: 19.1.6
resolution: "@types/react-dom@npm:19.1.6"
"@types/react-dom@npm:19.1.7":
version: 19.1.7
resolution: "@types/react-dom@npm:19.1.7"
peerDependencies:
"@types/react": ^19.0.0
checksum: 10/b5b20b7f0797f34c5a11915b74dcf8b3b7a9da9fea90279975ce6f150ca5d31bb069dbb0838638a5e9e168098aa4bb4a6f61d078efa1bbb55d7f0bdfe47bb142
checksum: 10/a99465e5a17d40725dedb3708357f8998c57caab768cee0992b4bb7822ce7ed2ec697a5f426cb98d3397b020756a6e4b0986dc5f6f4254e13b3536afb38538e6
languageName: node
linkType: hard
"@types/react@npm:19.1.8":
version: 19.1.8
resolution: "@types/react@npm:19.1.8"
"@types/react@npm:19.1.9":
version: 19.1.9
resolution: "@types/react@npm:19.1.9"
dependencies:
csstype: "npm:^3.0.2"
checksum: 10/a3e6fe0f60f22828ef887f30993aa147b71532d7b1219dd00d246277eb7a9ca01ec533096237fa21ca1bccb3653373b4e8e59e5ae59f9c793058384bbc1f4d5c
checksum: 10/b1032eae52e3b4f2a8b9ea6aac936385a78b7eff55cad4ff4f0d7e726c6ea87c1f287a1ba0e57a76a8e4456d3fb918b4f97a01e71686fdc11a65b26b8d296be4
languageName: node
linkType: hard
@@ -1369,9 +1369,9 @@ __metadata:
languageName: node
linkType: hard
"@uiw/codemirror-extensions-basic-setup@npm:4.23.13":
version: 4.23.13
resolution: "@uiw/codemirror-extensions-basic-setup@npm:4.23.13"
"@uiw/codemirror-extensions-basic-setup@npm:4.24.2":
version: 4.24.2
resolution: "@uiw/codemirror-extensions-basic-setup@npm:4.24.2"
dependencies:
"@codemirror/autocomplete": "npm:^6.0.0"
"@codemirror/commands": "npm:^6.0.0"
@@ -1388,7 +1388,7 @@ __metadata:
"@codemirror/search": ">=6.0.0"
"@codemirror/state": ">=6.0.0"
"@codemirror/view": ">=6.0.0"
checksum: 10/35fd1894f9f7da8f94fa077a70821f92118597e2e2b12782b254b0844f06c1855508421c4cb47de7099a972ef706218c08203116aa93da4e8e1585c8d234015d
checksum: 10/077f64b4bbb6178038d30a3cb2961c0ff89c0836b73210d0ac3fca828c3ba8fbce61e42635ec2e2997cdffff5472b75ad58541c4e62f98d52b83d475da0c56eb
languageName: node
linkType: hard
@@ -1408,14 +1408,14 @@ __metadata:
linkType: hard
"@uiw/react-codemirror@npm:^4.23.7":
version: 4.23.13
resolution: "@uiw/react-codemirror@npm:4.23.13"
version: 4.24.2
resolution: "@uiw/react-codemirror@npm:4.24.2"
dependencies:
"@babel/runtime": "npm:^7.18.6"
"@codemirror/commands": "npm:^6.1.0"
"@codemirror/state": "npm:^6.1.1"
"@codemirror/theme-one-dark": "npm:^6.0.0"
"@uiw/codemirror-extensions-basic-setup": "npm:4.23.13"
"@uiw/codemirror-extensions-basic-setup": "npm:4.24.2"
codemirror: "npm:^6.0.0"
peerDependencies:
"@babel/runtime": ">=7.11.0"
@@ -1423,9 +1423,9 @@ __metadata:
"@codemirror/theme-one-dark": ">=6.0.0"
"@codemirror/view": ">=6.0.0"
codemirror: ">=6.0.0"
react: ">=16.8.0"
react-dom: ">=16.8.0"
checksum: 10/51777d7eb313be0716d3597f829e6ee9982ab2dc3e36dc5219f25cdf680b82a6c0a0951d9adaca85b9c829da92f7971aa6e65bdd50e7610972d89463fe2587a1
react: ">=17.0.0"
react-dom: ">=17.0.0"
checksum: 10/f0816fcf40c451c8bc15319d62f5b8d62a04c12c2bc053569212b31edba7c7164e45fd161ebb683a03fd5a50697b91a6ac4cab2d2d1a45da5f2626d959c399a0
languageName: node
linkType: hard
@@ -2315,8 +2315,8 @@ __metadata:
"@storybook/react": "npm:^8.6.8"
"@types/mdx": "npm:^2.0.13"
"@types/node": "npm:^20"
"@types/react": "npm:19.1.8"
"@types/react-dom": "npm:19.1.6"
"@types/react": "npm:19.1.9"
"@types/react-dom": "npm:19.1.7"
"@uiw/codemirror-themes": "npm:^4.23.7"
"@uiw/react-codemirror": "npm:^4.23.7"
chokidar: "npm:^3.6.0"
@@ -2329,8 +2329,8 @@ __metadata:
next: "npm:15.3.4"
next-mdx-remote-client: "npm:^2.1.2"
prop-types: "npm:^15.8.1"
react: "npm:19.1.0"
react-dom: "npm:19.1.0"
react: "npm:19.1.1"
react-dom: "npm:19.1.1"
shiki: "npm:^1.26.1"
storybook: "npm:^8.6.8"
typescript: "npm:^5"
@@ -3618,20 +3618,20 @@ __metadata:
linkType: hard
"html-react-parser@npm:^5.2.5":
version: 5.2.5
resolution: "html-react-parser@npm:5.2.5"
version: 5.2.6
resolution: "html-react-parser@npm:5.2.6"
dependencies:
domhandler: "npm:5.0.3"
html-dom-parser: "npm:5.1.1"
react-property: "npm:2.0.2"
style-to-js: "npm:1.1.16"
style-to-js: "npm:1.1.17"
peerDependencies:
"@types/react": 0.14 || 15 || 16 || 17 || 18 || 19
react: 0.14 || 15 || 16 || 17 || 18 || 19
peerDependenciesMeta:
"@types/react":
optional: true
checksum: 10/22852dc4826d3be9506e238e37a05c23b432675aac33f22bd5741caa195a32e99de99d2b99037fda532f198afbcdeacfc0b27627d6e529143a98c8f191e99c52
checksum: 10/be2903fd932d44ff6cae66bd18b025d318879e16eb1e67c0ae6dc640e5c77509da41b61948c0d404a43b5362b57b7cfa3963df242b9773d4c7a16f410db7f2ac
languageName: node
linkType: hard
@@ -5135,20 +5135,20 @@ __metadata:
linkType: hard
"next-mdx-remote-client@npm:^2.1.2":
version: 2.1.2
resolution: "next-mdx-remote-client@npm:2.1.2"
version: 2.1.3
resolution: "next-mdx-remote-client@npm:2.1.3"
dependencies:
"@babel/code-frame": "npm:^7.27.1"
"@mdx-js/mdx": "npm:^3.1.0"
"@mdx-js/react": "npm:^3.1.0"
remark-mdx-remove-esm: "npm:^1.1.0"
remark-mdx-remove-esm: "npm:^1.2.0"
serialize-error: "npm:^12.0.0"
vfile: "npm:^6.0.3"
vfile-matter: "npm:^5.0.1"
peerDependencies:
react: ^19.1.0
react-dom: ^19.1.0
checksum: 10/610e95bff6c1dcdb4d1fefc9333ac748f1899cbca1ea551e784cd1e8cfd077c14d6bb8ab27826886f354cc3b9cf700fe25810263f996c53f824a2cfdbc5a064f
checksum: 10/3837c63edf7d707de2eea9b4c565eeb7e505a769e93c2673f746ec9993c644f7cd0aacb8bad911eff9ea63190f48c2c16ffe98d47c39591c5dac29c8bf9a9e0c
languageName: node
linkType: hard
@@ -5585,14 +5585,14 @@ __metadata:
languageName: node
linkType: hard
"react-dom@npm:19.1.0":
version: 19.1.0
resolution: "react-dom@npm:19.1.0"
"react-dom@npm:19.1.1":
version: 19.1.1
resolution: "react-dom@npm:19.1.1"
dependencies:
scheduler: "npm:^0.26.0"
peerDependencies:
react: ^19.1.0
checksum: 10/c5b58605862c7b0bb044416b01c73647bb8e89717fb5d7a2c279b11815fb7b49b619fe685c404e59f55eb52c66831236cc565c25ee1c2d042739f4a2cc538aa2
react: ^19.1.1
checksum: 10/9005415d2175b1f1eb4a544ad04afb29691bb7b6dd43bbdaa09932146b310b73bd4552bc772ad78fa481f409eada1560cf887606c83c1a53a922c1e30f1b3a34
languageName: node
linkType: hard
@@ -5610,10 +5610,10 @@ __metadata:
languageName: node
linkType: hard
"react@npm:19.1.0":
version: 19.1.0
resolution: "react@npm:19.1.0"
checksum: 10/d0180689826fd9de87e839c365f6f361c561daea397d61d724687cae88f432a307d1c0f53a0ee95ddbe3352c10dac41d7ff1ad85530fb24951b27a39e5398db4
"react@npm:19.1.1":
version: 19.1.1
resolution: "react@npm:19.1.1"
checksum: 10/9801530fdc939e1a7a499422e930515b2400809cb39c2872984e99f832d233f61659a693871183dac3155c2f9b2c9dcf4440a56bd18983277ae92860e38c3a61
languageName: node
linkType: hard
@@ -5754,7 +5754,7 @@ __metadata:
languageName: node
linkType: hard
"remark-mdx-remove-esm@npm:^1.1.0":
"remark-mdx-remove-esm@npm:^1.2.0":
version: 1.2.0
resolution: "remark-mdx-remove-esm@npm:1.2.0"
dependencies:
@@ -6480,21 +6480,21 @@ __metadata:
languageName: node
linkType: hard
"style-to-js@npm:1.1.16, style-to-js@npm:^1.0.0":
version: 1.1.16
resolution: "style-to-js@npm:1.1.16"
"style-to-js@npm:1.1.17, style-to-js@npm:^1.0.0":
version: 1.1.17
resolution: "style-to-js@npm:1.1.17"
dependencies:
style-to-object: "npm:1.0.8"
checksum: 10/a876cc49a29ac90c7723b4d6f002ac6c1ac5ccc6b5bc963d9c607cfc74b15927b704c9324df6f824f576c65689fe4b4ff79caabcd44a13d8a02641f721f1b316
style-to-object: "npm:1.0.9"
checksum: 10/431f2fca8a55a61939a83ff0f58638e2996621ad93a97cf93f2be5115f411330d4e506ccf18621bd45607ec161546b763bb6961ad08238ad939b6261ff377230
languageName: node
linkType: hard
"style-to-object@npm:1.0.8":
version: 1.0.8
resolution: "style-to-object@npm:1.0.8"
"style-to-object@npm:1.0.9":
version: 1.0.9
resolution: "style-to-object@npm:1.0.9"
dependencies:
inline-style-parser: "npm:0.2.4"
checksum: 10/530b067325e3119bfaf75bdbe25cc86b02b559db00d881a74b98a2d5bb10ac953d1b455ed90c825963cf3b4bdaa1bda45f406d78d987391434b8d8ab3835df4e
checksum: 10/fd0c131a83103fe4025afd8e0fd90c605054d485ad80f2ab402e7afa79f482f4b05fff40b6aa661cb1b835e5c56bb0644dc38cbf9b3d2982fc552435db3dae50
languageName: node
linkType: hard
@@ -0,0 +1,77 @@
---
id: adrs-adr015
title: 'ADR015: Types and naming for element and component options'
description: Architecture Decision Record (ADR) for the proper types and naming for element and component options
---
## Context
Until now there hasn't been a clear standard for how to define options that are intended to provide JSX elements or components. This led to a mix of different patterns in public APIs, which this ADR aims to standardize.
## Decision
We will use one of the following option property names and types when defining options that are intended to provide JSX elements or components:
### Simple element
This option is used when a simple synchronous JSX element is provided. It must only be used in areas where lazy-loading is not needed.
```tsx
{
element: JSX.Element;
}
```
### Simple component
This option is used when a simple synchronous component is provided. It must only be used in areas where lazy-loading is not needed.
```tsx
{
component: (props: { ... }) => JSX.Element | null
}
```
### Async element loader
This option is used when a simple asynchronous JSX element is provided. It is the preferred option when only producing a single instance and there is no need to pass properties to the component. This format simplifies the creation of closures for passing additional properties in the loader implementation.
```tsx
{
loader: () => Promise<JSX.Element>;
}
```
### Async component loader
This option is used when a simple asynchronous component is provided. It is the preferred option when properties need to be passed to the component or multiple instance are needed, and lazy-loading is required.
```tsx
{
loader: () => Promise<(props: { ... }) => JSX.Element | null>
}
```
### Any component loader
This option is used in the same cases as the async component loader, but when the option of synchronous loading is also needed. The structure of always having the outer loader function, even in the synchronous case, makes it possible to determine the type of the loader at runtime.
```tsx
{
loader: (() => props => JSX.Element | null) | (() => Promise<props => JSX.Element | null>)
}
```
Note that when consuming this loader we'll need to unconditionally wrap it with `React.lazy`. This is because you can't delay the call to `React.lazy` until rendering, because you're not allowed to call it within a render function. This means that we can't first call the loader to check whether the returned value is a promise or not, and we must instead unconditionally wrap it with `React.lazy`. Therefore the implementation of accepting one of these loaders as an option needs to look something like this:
```tsx
const LazyComponent = React.lazy(() =>
Promise.resolve(options.loader()).then(loaded => ({ default: loaded })),
);
```
## Consequences
We will update all APIs for the new frontend system in the `@backstage/frontend-*` packages.
We will not update any of the existing APIs for the old frontend system in the `@backstage/core-*` packages.
@@ -366,7 +366,7 @@ your first set of parameter fields would be shown. The same goes for the nested
spec. Make sure to use the key `backstage:featureFlag` in your templates if
you want to use this functionality.
Feature Flags cannot be used in `spec.steps[].if`(the conditional on whether to execute an step/action). But you can use feature flags to display parameters that allow for skipping steps.
Feature Flags cannot be used in `spec.steps[].if`(the conditional on whether to execute a step/action). But you can use feature flags to display parameters that allow for skipping steps.
```yaml
spec:
@@ -807,7 +807,7 @@ Have in mind that changes in this form will not be saved on the template and is
### Custom Field Explorer
The custom filed explorer allows you to select any custom field loaded on the backstage instance and test different values and configurations.
The custom field explorer allows you to select any custom field loaded on the backstage instance and test different values and configurations.
## Presentation
+11 -14
View File
@@ -48,31 +48,28 @@ App feature discovery lets you automatically discover and install features provi
Because feature discovery needs to interact with the compilation process, it is only available when using the `@backstage/cli` to build your app. It is hooked into the WebPack compilation process by scanning your app package for compatible dependencies, which are then made part of the app compilation bundle.
Since the `@backstage/cli` is a more stable component than the new frontend system, feature discovery is currently marked as an experimental feature of the CLI and needs to be enabled manually. To enable it, add the following configuration to your `app-config.yaml`:
To enable frontend feature discovery, add the following configuration to your `app-config.yaml`:
```yaml
app:
experimental:
packages: all
packages: all
```
This will cause all dependencies in your app package to be installed automatically. If this is not desired, you can use include or exclude filters to narrow down the set of packages:
```yaml
app:
experimental:
packages:
# Only the following packages will be included
include:
- '@backstage/plugin-catalog'
- '@backstage/plugin-scaffolder'
packages:
# Only the following packages will be included
include:
- '@backstage/plugin-catalog'
- '@backstage/plugin-scaffolder'
---
app:
experimental:
packages:
# All but the following package will be included
exclude:
- '@backstage/plugin-catalog'
packages:
# All but the following package will be included
exclude:
- '@backstage/plugin-catalog'
```
Note that you do not need to manually exclude packages that you also import explicitly in code, since plugin instances are deduplicated by the app. You will never end up with duplicate plugin installations except if they are in fact two different plugin instances with different IDs.
@@ -21,7 +21,7 @@ Frontend plugin instances are created with the `createFrontendPlugin` function,
// This creates a new extension, see "Extension Blueprints" documentation for more details
const myPage = PageBlueprint.make({
params: {
defaultPath: '/my-page',
path: '/my-page',
loader: () => import('./MyPage').then(m => <m.MyPage />),
},
});
@@ -107,7 +107,7 @@ export default plugin.withOverrides({
// Override the catalog index page with a completely custom implementation
PageBlueprint.make({
params: {
defaultPath: '/catalog',
path: '/catalog',
routeRef: plugin.routes.catalogIndex,
loader: () => import('./CustomCatalogIndexPage').then(m => <m.Page />),
},
@@ -18,7 +18,7 @@ The following is a simple example of how one might use the blueprint `make` meth
```tsx
const myPageExtension = PageBlueprint.make({
params: {
defaultPath: '/my-page',
path: '/my-page',
loader: () => import('./components/MyPage').then(m => <m.MyPage />),
},
});
@@ -26,7 +26,7 @@ const myPageExtension = PageBlueprint.make({
The returned `myPageExtension` is an extension which is ready to be used in a plugin. It is the same type of object as is returned by the lower level `createExtension` function.
## Creating an extension from a blueprint with overrides
### Creating an extension from a blueprint with overrides
Every extension blueprint also provides a `makeWithOverrides` method. It is useful in cases where you want to provide additional integration points for an extension created with a blueprint. You might for example want to define additional inputs or configuration schema, or use the existing configuration to dynamically compute the parameters passed to the blueprint.
@@ -34,22 +34,34 @@ The following is an example of how one might use the blueprint `makeWithOverride
```tsx
const myPageExtension = PageBlueprint.makeWithOverrides({
// This defines additional configuration options for the extension.
config: {
schema: {
layout: z => z.enum(['grid', 'rows']).default('grid'),
},
},
// The original blueprint factory is provided as the first argument
factory(originalFactory, { config }) {
// This defines additional inputs for the extension.
inputs: {
content: createExtensionInput([coreExtensionData.reactElement], {
singleton: true,
optional: true,
}),
},
// The original blueprint factory is provided as the first argument.
// By convention the name is `originalFactory`, but you can also pick a different name.
factory(originalFactory, { config, inputs }) {
// Call and forward the result from the original factory, providing
// the blueprint parameters as the first argument.
return originalFactory({
defaultPath: '/my-page',
path: '/my-page',
loader: () =>
import('./components/MyPage').then(m => (
// We can now access values from the factory context when providing
// the blueprint parameters, such as config values.
<m.MyPage layout={config.layout} />
// the blueprint parameters, such as config values and inputs.
<m.MyPage
layout={config.layout}
content={inputs.content?.get(coreExtensionData.reactElement)}
/>
)),
});
},
@@ -58,18 +70,18 @@ const myPageExtension = PageBlueprint.makeWithOverrides({
When using `makeWithOverrides`, we no longer pass the blueprint parameters directly. Instead, we provide a `factory` function that receives the original blueprint factory as the first argument, and the extension factory context as the second. We can then call the original blueprint factory with the blueprint parameters and forward the result as the return value of out factory. Notice that when passing the blueprint parameters using this pattern we have access to a lot more information than when using the `make` method, at the cost of being more complex.
Apart from the addition of the blueprint parameters of the first argument to the original factory function, the `makeWithOverrides` method works the same way as [extension overrides](./25-extension-overrides.md). All the same options and rules apply, including the ability to define additional inputs, override outputs, and so on. We therefore defer to the [extension overrides](./25-extension-overrides.md) documentation for more information on how to use the `makeWithOverrides` method.
Apart from the addition of the blueprint parameters of the first argument to the original factory function, the `makeWithOverrides` method works the same way as [extension overrides](./25-extension-overrides.md). All the same options and rules apply, including the ability to define additional inputs, override outputs, and so on. For more details and examples on how this works, please refer to the [extension overrides](./25-extension-overrides.md) documentation. The patterns in that section also apply to the creation of extensions with the `makeWithOverrides` method.
### Creating an extension from a blueprint with advanced parameter types
Some blueprints may be defined with something known as "advanced parameter types". This is a feature that enables type inference and transform of the blueprint parameters, and the way that you pass the parameters look a little bit different. Rather than passing the parameters directly, they are instead passed as a callback function of the form `define => define(<params>)`.
Some blueprints may be defined with something known as "advanced parameter types". This is a feature that enables type inference and transform of the blueprint parameters, and the way that you pass the parameters look a little bit different. Rather than passing the parameters directly, they are instead passed as a callback function of the form `defineParams => defineParams(<params>)`.
An example of a blueprint that uses advanced parameter types is the `ApiBlueprint` blueprint. Using it to create a simple implementation for the `AlertApi` might look like this:
```ts
const alertApiBlueprint = ApiBlueprint.make({
params: define =>
define({
params: defineParams =>
defineParams({
api: alertApiRef,
deps: {},
factory: () => new MyAlertApi(),
@@ -82,8 +94,8 @@ This also works with `makeWithOverrides`, where the define callback is passed as
```ts
const alertApiBlueprint = ApiBlueprint.makeWithOverrides({
factory(originalFactory, { config }) {
return originalFactory(define =>
define({
return originalFactory(defineParams =>
defineParams({
api: alertApiRef,
deps: {},
factory: () => new MyAlertApi(config),
@@ -101,7 +113,7 @@ The following is an example of how one might create a new extension blueprint:
```tsx
export interface MyWidgetBlueprintParams {
defaultTitle: string;
title: string;
element: JSX.Element;
}
@@ -119,7 +131,7 @@ export const MyWidgetBlueprint = createExtensionBlueprint({
// Note that while this is a valid pattern, you might often want to
// return separate pieces of data instead, more on that below.
coreExtensionData.reactElement(
<MyWidgetContainer title={config.title ?? params.defaultTitle}>
<MyWidgetContainer title={config.title ?? params.title}>
{params.element}
</MyWidgetContainer>,
),
@@ -175,7 +187,7 @@ To do that, we create a new extension data reference for our widget title. This
```tsx
export interface MyWidgetBlueprintParams {
defaultTitle: string;
title: string;
element: JSX.Element;
}
@@ -194,7 +206,7 @@ export const MyWidgetBlueprint = createExtensionBlueprint({
output: [widgetTitleRef, coreExtensionData.reactElement],
factory(params: MyWidgetBlueprintParams, { config }) {
return [
widgetTitleRef(config.title ?? params.defaultTitle),
widgetTitleRef(config.title ?? params.title),
coreExtensionData.reactElement(params.element),
];
},
@@ -89,7 +89,7 @@ const exampleExtension = PageBlueprint.make({
params: {
loader: () =>
import('./components/ExamplePage').then(m => <m.ExamplePage />),
defaultPath: '/example',
path: '/example',
},
});
```
@@ -318,7 +318,7 @@ import {
const customSearchPage = PageBlueprint.make({
params: {
defaultPath: '/search',
path: '/search',
loader: () =>
import('./CustomSearchPage').then(m => <m.CustomSearchPage />),
},
+42 -3
View File
@@ -47,7 +47,7 @@ import { indexRouteRef } from './routes';
const catalogIndexPage = createPageExtension({
// The `name` option is omitted because this is an index page
defaultPath: '/entities',
path: '/entities',
// highlight-next-line
routeRef: indexRouteRef,
loader: () => import('./components').then(m => <m.IndexPage />),
@@ -197,7 +197,7 @@ import {
import { indexRouteRef, createComponentExternalRouteRef } from './routes';
const catalogIndexPage = createPageExtension({
defaultPath: '/entities',
path: '/entities',
routeRef: indexRouteRef,
loader: () => import('./components').then(m => <m.IndexPage />),
});
@@ -404,7 +404,7 @@ import {
import { indexRouteRef, detailsSubRouteRef } from './routes';
const catalogIndexPage = createPageExtension({
defaultPath: '/entities',
path: '/entities',
routeRef: indexRouteRef,
loader: () => import('./components').then(m => <m.IndexPage />),
});
@@ -419,3 +419,42 @@ export default createFrontendPlugin({
extensions: [catalogIndexPage],
});
```
## Route Aliases - Overriding Routed Extensions in Modules
It is possible to [override extensions of a plugin using a module](./25-extension-overrides.md#creating-a-frontend-module). In some cases the extension you're overriding may require a route reference. You could import import the plugin instance and access the it via the `routes` property, but this creates a direct dependency on the plugin and risks leading to package duplication issues that would also break the route reference.
Instead of accessing the route reference directly, you can create a new route reference that acts as an alias for the original one from the plugin. For example, you can override the catalog index page with a custom one like this:
```tsx
const indexRouteRef = createRouteRef({ aliasFor: 'catalog.catalogIndex' });
export default createFrontendModule({
pluginId: 'catalog',
extensions: [
PageBlueprint.make({
params: {
defaultPath: '/catalog',
routeRef: indexRouteRef,
loader: () =>
import('./CustomCatalogIndexPage').then(m => (
<m.CustomCatalogIndexPage />
)),
},
}),
],
});
```
Aliases are limited to the plugin that they are defined in. These aliases can also be imported and used as usual with for example `useRouteRef`, but they must always be registered in the app via an extension for this to work. For example, the following will not work:
```tsx
function MyInvalidComponent() {
// This is NOT valid
const link = useRouteRef(
createRouteRef({ aliasFor: 'catalog.catalogIndex' }),
);
// ...
}
```
@@ -42,7 +42,7 @@ The conversion functions such as `convertLegacyPageExtension` will attempt to in
```ts
const convertedIndexPage = convertLegacyPageExtension(TechDocsIndexPage, {
name: 'index',
defaultPath: '/docs',
path: '/docs',
});
```
@@ -72,10 +72,10 @@ const convertedTechdocsPlugin = convertLegacyPlugin(techdocsPlugin, {
extensions: [
convertLegacyPageExtension(TechDocsIndexPage, {
name: 'index',
defaultPath: '/docs',
path: '/docs',
}),
convertLegacyPageExtension(TechDocsReaderPage, {
defaultPath: '/docs/:namespace/:kind/:name/*',
path: '/docs/:namespace/:kind/:name/*',
}),
convertLegacyEntityContentExtension(EntityTechdocsContent),
],
@@ -199,8 +199,8 @@ import { ApiBlueprint } from '@backstage/frontend-plugin-api';
const scmIntegrationsApi = ApiBlueprint.make({
name: 'scm-integrations',
params: define =>
define({
params: defineParams =>
defineParams({
api: scmIntegrationsApiRef,
deps: { configApi: configApiRef },
factory: ({ configApi }) => ScmIntegrationsApi.fromConfig(configApi),
@@ -244,8 +244,7 @@ Plugins don't even have to be imported manually after installing their package i
```yaml title="in app-config.yaml"
app:
# Enabling plugin and override features discovery
experimental:
packages: all # ✨
packages: all # ✨
```
### `featureFlags`
@@ -75,7 +75,7 @@ const examplePage = PageBlueprint.make({
routeRef: rootRouteRef,
// This is the default path of this page, but integrators are free to override it
defaultPath: '/example',
path: '/example',
// Page extensions are always dynamically loaded using React.lazy().
// All of the functionality of this page is implemented in the
@@ -160,8 +160,8 @@ import { exampleApiRef, DefaultExampleApi } from './api';
// highlight-add-start
const exampleApi = ApiBlueprint.make({
name: 'example',
params: define =>
define({
params: defineParams =>
defineParams({
api: exampleApiRef,
deps: {},
factory: () => new DefaultExampleApi(),
@@ -198,8 +198,8 @@ import { EntityContentBlueprint } from '@backstage/plugin-catalog-react/alpha';
// route reference if you want to be able to generate a URL that links to the content.
const exampleEntityContent = EntityContentBlueprint.make({
params: {
defaultPath: 'example',
defaultTitle: 'Example',
path: 'example',
title: 'Example',
loader: () =>
import('./components/ExampleEntityContent').then(m => (
<m.ExampleEntityContent />
@@ -17,10 +17,6 @@ These are the [extension blueprints](../architecture/23-extension-blueprints.md)
An API extension is used to add or override [Utility API factories](../utility-apis/01-index.md) in the app. They are commonly used by plugins for both internal and shared APIs. There are also many built-in Api extensions provided by the framework that you are able to override.
### Component - [Reference](../../reference/frontend-plugin-api.createcomponentextension.md)
Components extensions are used to override the component associated with a component reference throughout the app. This uses an extension creator function rather than a blueprint, but will likely be migrated to a blueprint in the future.
### NavItem - [Reference](../../reference/frontend-plugin-api.navitemblueprint.md)
Navigation item extensions are used to provide menu items that link to different parts of the app. By default nav items are attached to the app nav extension, which by default is rendered as the left sidebar in the app.
@@ -33,6 +29,10 @@ Page extensions provide content for a particular route in the app. By default pa
Sign-in page extension have a single purpose - to implement a custom sign-in page. They are always attached to the app root extension and are rendered before the rest of the app until the user is signed in.
### SwappableComponent - [Reference](../../reference/frontend-plugin-api.swappablecomponentblueprint.md)
Swappable Components are extensions that are used to replace the implementations of components in the app and plugins.
### Theme - [Reference](../../reference/frontend-plugin-api.themeblueprint.md)
Theme extensions provide custom themes for the app. They are always attached to the app extension and you can have any number of themes extensions installed in an app at once, letting the user choose which theme to use.
@@ -119,7 +119,7 @@ const fooPage = PageBlueprint.make({
params: {
// This is the path that was previously defined in the app code.
// It's labelled as the default one because it can be changed via configuration.
defaultPath: '/foo',
path: '/foo',
// You can reuse the existing routeRef by wrapping it with convertLegacyRouteRef.
routeRef: convertLegacyRouteRef(rootRouteRef),
// these inputs usually match the props required by the component.
@@ -210,8 +210,8 @@ import { workApiRef } from '@internal/plugin-example-react';
import { WorkImpl } from './WorkImpl';
const exampleWorkApi = ApiBlueprint.make({
params: define =>
define({
params: defineParams =>
defineParams({
api: workApiRef,
deps: { storageApi: storageApiRef },
factory: ({ storageApi }) => new WorkImpl({ storageApi }),
@@ -62,8 +62,8 @@ class WorkImpl implements WorkApi {
const workApi = ApiBlueprint.make({
name: 'work',
params: define =>
define({
params: defineParams =>
defineParams({
api: workApiRef,
deps: { storageApi: storageApiRef },
factory: ({ storageApi }) => {
@@ -51,8 +51,8 @@ import {
import { MyApiImpl } from './MyApiImpl';
const myApi = ApiBlueprint.make({
params: define =>
define({
params: defineParams =>
defineParams({
api: myApiRef,
deps: {
configApi: configApiRef,
+32
View File
@@ -101,6 +101,25 @@ export const apis: AnyApiFactory[] = [
},
}),
];
// Or, when building for the new frontend system:
import { AnalyticsImplementationBlueprint } from '@backstage/frontend-plugin-api';
export const acmeAnalyticsImplementation =
AnalyticsImplementationBlueprint.make({
name: 'acme',
params: define =>
define({
deps: {},
factory() {
return {
captureEvent: event => {
window._AcmeAnalyticsQ.push(event);
},
};
},
}),
});
```
In reality, you would likely want to encapsulate instantiation logic and pull
@@ -140,6 +159,19 @@ export const apis: AnyApiFactory[] = [
factory: ({ configApi }) => AcmeAnalytics.fromConfig(configApi),
}),
];
// Or, when building for the new frontend system:
import { AnalyticsImplementationBlueprint } from '@backstage/frontend-plugin-api';
export const acmeAnalyticsImplementation =
AnalyticsImplementationBlueprint.make({
name: 'acme',
params: define =>
define({
deps: { configApi: configApiRef },
factory: ({ configApi }) => AcmeAnalytics.fromConfig(configApi),
}),
});
```
If you are integrating with an analytics service (as opposed to an internal
+171 -88
View File
@@ -6,19 +6,21 @@ description: List of terms, abbreviations, and phrases used in Backstage, togeth
## Access Token
A [token](#token) that gives access to perform actions on behalf of a user. It will commonly have a short expiry time, and be limited to a set of [scopes](#scope). Part of the [OAuth](#oauth) protocol, see [their docs](https://oauth.net/2/access-tokens/) for more information.
A [token](#token) that represents the authorization to access resources on behalf of the end-user in a way that hides the user's actual identity. It will commonly have a short expiry time, and be limited to a set of [scopes](#scope). Part of the [OAuth](#oauth) protocol, see [their docs](https://oauth.net/2/access-tokens/) for details.
## Administrator
Someone responsible for installing, configuring, and maintaining a Backstage [app](#app) for an organization. A [user role](#user-role).
## API (catalog plugin)
## API
An [entity](#entity) representing a schema that two [components](#component) use to communicate. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
A software interface consisting of defined rules, protocols, and tools, that allows two applications or [components](#component-catalog-plugin) to communicate and exchange data or functionality.
APIs are key abstractions that allow large software ecosystems to be scaled efficiently. Within the Backstage model, APIs are first-class citizens, and are the primary method for discovering existing functionality across the ecosystem. See [Backstage System Model](https://backstage.io/docs/features/software-catalog/system-model/#api).
## App
An installed instance of Backstage. An app can be local, intended for a single development group or individual developer, or organizational, for use by an entire enterprise.
An installed instance of Backstage. An app can be local, intended for a single developer or development group, or organizational, for use by an entire enterprise.
## Authentication
@@ -26,21 +28,21 @@ The process of verifying the identity of a user, system, or entity attempting to
## Authorization
The process of determining what an authenticated user or system is allowed to do within a system, application, or resource. It comes after authentication, and answers the question: "What are you allowed to access or do?" It involves assigning specific privileges or access rights or roles to the user. See [this Wikipedia article](https://en.wikipedia.org/wiki/Authorization) for more details.
The process of determining which operations an authenticated user or system is allowed to perform within a system, application, or resource. It comes after authentication, and answers the question: "What are you allowed to access or do?" It involves assigning specific privileges, access rights, or roles to the user. See [this Wikipedia article](https://en.wikipedia.org/wiki/Authorization) for more details.
## Authorization Code
## Authorization Code Grant
A type of [OAuth flow](#oauth) used by confidential and public clients to get an [access token](#access-token). See [the OAuth docs](https://oauth.net/2/grant-types/authorization-code/) for more details.
See [Code Grant](#code-grant).
## Backstage
1. An open source framework for creating and deploying [developer portals](#developer-portal), originally created at Spotify. Backstage is an incubation-stage open source project of the [Cloud Native Computing Foundation](#cloud-native-computing-foundation).
1. An open source framework for creating and deploying [developer portals](#developer-portal), originally created at Spotify. Backstage is an incubation-stage open source project of the [Cloud Native Computing Foundation](#cloud-native-computing-foundation-aka-cncf).
2. [The Backstage Framework](#backstage-framework).
## Backstage Framework
The actual framework that Backstage [plugins](#plugin) sit on. This spans both the frontend and the backend, and includes core functionality such as declarative integration, config reading, database management, and many more.
The actual framework that Backstage [plugins](#plugin) sit on. The framework spans the frontend and backend, and includes core functionality such as declarative integration, config reading, database management, and much more.
## Bundle
@@ -50,43 +52,49 @@ The actual framework that Backstage [plugins](#plugin) sit on. This spans both t
## Catalog
1. The core Backstage plugin that handles ingestion and display of your organization's software products.
2. An organization's portfolio of software products managed in Backstage.
See [Software Catalog](#software-catalog).
## Cloud Native Computing
A set of technologies that "empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach." ([CNCF Cloud Native Definition v1.0](https://github.com/cncf/toc/blob/main/DEFINITION.md)).
A set of technologies that "empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach." ([CNCF Cloud Native Definition v1.1](https://github.com/cncf/toc/blob/main/DEFINITION.md)).
## Cloud Native Computing Foundation (AKA CNCF)
## Cloud Native Computing Foundation (aka CNCF)
A foundation dedicated to the promotion and advancement of [Cloud Native Computing](#Cloud-Native-Computing). The mission of the Cloud Native Computing Foundation (CNCF) is "to make cloud native computing ubiquitous" ([CNCF Charter](https://github.com/cncf/foundation/blob/main/charter.md)).
A foundation dedicated to the promotion and advancement of [Cloud Native Computing](#cloud-native-computing). The mission of the Cloud Native Computing Foundation (CNCF) is "to make cloud native computing ubiquitous" ([CNCF Charter](https://github.com/cncf/foundation/blob/main/charter.md)).
CNCF is part of the [Linux Foundation](https://www.linuxfoundation.org/).
## Code Grant
[OAuth](#oauth) flow where the client receives an [authorization code](#code) that is passed to the backend to be exchanged for an [access token](#access-token) and possibly a [refresh token](#refresh-token).
In the context of [OAuth 2.0](https://oauth.net/2/), refers to the process where an application receives an [authorization code](#authorization-code-grant) after a user grants it permission to access their resources. This code is then exchanged for an [access token](#access-token) and possibly a [refresh token](#refresh-token), which the application uses to access the user's data on their behalf. It's a secure way for applications to access protected resources without directly handling the user's credentials. See the [OAuth docs](https://oauth.net/2/grant-types/authorization-code/) for details.
## Collator (search plugin)
A transformer that takes streams of [documents](#documents) and outputs searchable texts. They're usually responsible for the data transformation and definition and collection process for specific [documents](#documents).
A specialized component of Backstage that's responsible for ordering or indexing data according to a specific set of rules. In Backstage search, collators are used to define what can be searched. Specifically, they're readable object streams of documents that contain a minimum set of fields (including document title, location, and text), but can contain any other fields as defined by the collator itself. A single collator is responsible for defining and collecting documents of a specific type.
Backstage includes "default" collators for Catalog and TechDocs that you can use out-of-the-box to start searching across Backstage quickly. More collators are available from the Backstage community. Learn more at [Collators](https://backstage.io/docs/features/search/collators).
## Component (catalog plugin)
A software product that is managed in the Backstage [Software Catalog](#software-catalog). A component can be a service, website, library, data pipeline, or any other piece of software managed as a single project. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
1. A modular, independent, reusable software-based unit that encapsulates specific functionality. It has well-defined interfaces, explicitly specified dependencies, and is designed to be integrated with other components to build larger software systems.
2. A software product that Backstage manages in the [Software Catalog](#software-catalog). A component can be a service, website, library, data pipeline, or any other software artifact that's managed as a single entity.
A Backstage component can implement [API](#api)s for other components to consume. In turn, it might consume APIs implemented by other components, or directly depend on components or resources that are attached to it at runtime.
See the [Backstage System Model](https://backstage.io/docs/features/software-catalog/system-model/#component-catalog-plugin).
## Condition (permission plugin)
A mapping from a given entity to criteria a user must fulfill to perform an action on that entity. Examples include `isOwner`, `hasRole`, etc.
A criterion, evaluated on an entity, that a user must meet to be granted permission to perform an action on that entity within a permission plugin. Examples might include `isOwner` or `hasRole`.
## Conditional Decision (permission plugin)
A type of [decision](#policy-decision-permission-plugin) that allows for per-user evaluation of [conditions](#condition-permission-plugin) against a [resource](#resource-permission-plugin). See [Conditional Decisions](../permissions/concepts.md#conditional-decisions)
A [decision](#policy-decision-permission-plugin) mechanism, common in permission plugins, that evaluates real-time conditions (predicates) on a per-user basis to determine access or actions against a [resource](#resource-permission-plugin). This enables highly granular, context-aware control. See [Conditional Decisions](https://backstage.io/docs/permissions/concepts/#conditional-decisions).
## Contributor
A volunteer who helps to improve an OSS product such as Backstage. This volunteer effort includes coding, testing, technical writing, user support, and other work. A [user role](#user-role).
A volunteer who helps to improve an open source product such as Backstage. This volunteer effort includes coding, testing, technical writing, user support, and other work. A [user role](#user-role).
## Declarative Integration
@@ -94,11 +102,13 @@ A new paradigm for Backstage frontend plugins, allowing definition in config fil
## Decorator (search plugin)
A transform stream that allows you to add additional information to [documents](#document-search-plugin).
A transform stream that operates during the indexing process, positioned between a [Collator](#collator-search-plugin) (read stream) and an Indexer (write stream). Document Decorators are used to modify documents by adding, removing, or filtering metadata, or even injecting new documents, as they are being prepared for the search index.
To illustrate, while the [Software Catalog](#software-catalog) understands software entities, it might not track their usage or quality. A decorator can add this extra metadata, which can then be used to bias search results or enhance the search experience within your Backstage instance.
## Deployment Artifacts
An executable or package file with all of the necessary information required to deploy the application at runtime. Deployment artifacts can be hosted on [package registries](#package-registry).
An executable or [package](#package) file with all of the necessary information required to deploy at runtime. Deployment artifacts can be hosted on [package registries](#package-registry).
## Developer
@@ -108,64 +118,88 @@ An executable or package file with all of the necessary information required to
## Developer Portal
A centralized system comprising a user interface and database used to facilitate and document all the software projects within an organization. Backstage is both a developer portal and (by virtue of being based on plugins) a framework for creating developer portals.
1. A centralized, self-service interface providing developers with all the necessary resources, tools, documentation, and information to effectively build, integrate, deploy, and manage software products within an organization.
2. Backstage is a specific example of a developer portal, designed as a centralized system with a user interface and database to streamline development and maintenance of an organization's software projects. It features a robust [Software Catalog](#software-catalog) that centralizes and organizes access to the organization's services, websites, mobile features, libraries, and other software components. Backstage also includes [Software Templates](#software-templates-aka-scaffolder) that simplify the creation of new projects and components.
Backstage is both a developer portal and a plugin-based framework for creating new custom developer portals.
## Document (search plugin)
1. A piece of information or data that is recorded on some medium for the purpose of storing and conveying information.
1. A piece of information or data that is recorded on some medium for the purpose of retention and conveyance.
2. An abstract concept representing something that can be found by searching for it. A document can represent a software entity, a TechDocs page, etc. Documents are made up of metadata fields, at a minimum -- a title, body (text), and location (as in a URL).
2. An abstract representation of information or data that can be discovered and retrieved. For search purposes, a document might represent a software entity, a TechDocs page, or any other type of data that is indexed. In Backstage, a document is structured with metadata fields that must include at least a title, a body (containing its core text content), and a location (such as a URL pointing to its source).
## Domain
1. A collection of systems that share terminology, domain models, metrics, KPIs, business purpose, or documentation; that is, it forms a bounded context.
2. An area that relates systems or entities to a business unit. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
2. Typically the unique, human-readable address that is used to identify websites, email servers, and other resources on the internet, such as `google.com` or `example.store`. More narrowly, it can refer to the Top-Level Domain (TLD), which is the part of a web address after the last dot, such as `.com` or `.org`; the country code, such as `.us` or `.uk`; or the sponsored TLD such as `.gov` or `.edu`.
3. An area that relates systems or entities to a business unit. See [Domain](https://backstage.io/docs/features/software-catalog/system-model/#domain) in the [System Model](https://backstage.io/docs/features/software-catalog/system-model/).
## Entity
1. Something that exists as a separate and distinct unit. Its existence can be real or abstract, physical or conceptual, persistent or ephemeral.
2. What is cataloged in the Backstage Software Catalog. An entity is identified by a unique combination of [kind](#Kind), [namespace](#Namespace), and name. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
2. What is cataloged in the Backstage [Software Catalog](#software-catalog). An entity is identified by a unique combination of [kind](#kind), [namespace](#namespace-catalog-plugin), and name. See [The Life of an Entity](https://backstage.io/docs/features/software-catalog/life-of-an-entity) for related key concepts and how it's handled.
## Evaluator
Someone who assesses whether Backstage is a suitable solution for their organization. The only [user role](#user-role) with a pre-deployment [use case](#use-case).
Someone who assesses whether Backstage is a suitable solution for their organization and needs. The only [user role](#user-role) with a pre-deployment [use case](#use-case).
## ID Token
A security token used in authentication processes, primarily defined by the [OpenID Connect (OIDC) standard](#openid-connect). Its main purpose is to prove that a user has been successfully authenticated by an identity provider.
See [JSON Web Token](#json-web-token).
A security token used in authentication processes, primarily defined by the [OpenID Connect (OIDC) standard](#openid-connect-aka-oidc). Its main purpose is to prove that a user has been successfully authenticated by an identity provider. See [JSON Web Token](#json-web-token-aka-jwt).
## Index (search plugin)
A collection of [documents](#documents) of a given type.
A collection of [documents](#document-search-plugin) that a search engine uses to quickly locate relevant information within your developer portal. It's essentially a lookup table that allows you to quickly find documents without having to scan the entire dataset.
## Indexer (search plugin)
A write stream of [documents](#documents).
In Backstage's Search Platform, the term _indexer_ isn't a component or concept that developers typically interact with. Instead, it refers to the overall process or the _write stream_ within the Search backend that takes processed documents and adds them to the chosen search engine's index.
To understand _indexer_ in Backstage, it's helpful to understand the flow of data into the Search system:
1. A [Collator](#collator-search-plugin) reads raw data from a specific source and transforms it into a stream of [documents](#document-search-plugin), where each document is formatted in a way the search platform understands (e.g., having title, text, location fields, and potentially other metadata).
2. As the stream of documents flows from the collator, a [decorator](#decorator-search-plugin) can intercept them. The decorator optionally adds, removes, or modifies fields within the documents to enrich them with context that the original collator might not have (such as adding ownership information from the Catalog to TechDocs documents).
3. After optional decoration, the stream of finalized search documents is then written to the search engine's index. This is what the term _indexer_ implicitly refers to. It's the functionality that takes these structured documents and inserts them into the chosen search engine (like Lunr, PostgreSQL, or Elasticsearch) so they become searchable.
The `plugin-search-backend-node` package in Backstage is responsible for orchestrating this entire indexing process. It manages the collators, decorators, the connection to the specific search engine, and the scheduling of when these indexing tasks run.
## Integrator
Someone who develops one or more plugins that enable Backstage to interoperate with another software system. A [user role](#user-role).
1. Someone who develops one or more plugins that enable Backstage to interoperate with another software system. A [user role](#user-role).
## JSON Web Token (AKA JWT)
2. May refer to someone who develops software that integrates with Backstage.
A popular, compact, and self-contained open standard for securely transmitting information between parties as a JSON object. It is commonly used to verify a user's identity [authentication](#authentication) and permissions [authorization](#authorization). Each JWT consists of a header, payload, and digital signature separated by dots. While often encrypted, JWTs are always signed for integrity. This standard is a key component of [OpenID Connect](#openid-connect). For more details, see [the Wikipedia article](https://en.wikipedia.org/wiki/JSON_Web_Token).
## JSON Web Token (aka JWT)
A popular, compact, and self-contained open standard for securely transmitting information between parties as a JSON object. It is commonly used to verify a user's identity ([authentication](#authentication)) and permissions ([authorization](#authorization)). Each JWT consists of a header, payload, and digital signature separated by dots. JWTs are often encrypted, and are always signed for integrity.
This standard is a key component of [OpenID Connect](#openid-connect-aka-oidc). For more details, see [this Wikipedia article](https://en.wikipedia.org/wiki/JSON_Web_Token).
## Kind
Classification of an [entity](#Entity) in the Backstage Software Catalog, for example _service_, _database_, and _team_.
Classification of an [entity](#entity) in the Backstage Software Catalog, for example _service_, _database_, or _team_. An element of the [kind|namespace|name triplet](#kind-namespace-name-triplet) that is an important concept for uniqueness.
## Kubernetes (CNCF Project)
## Kind|namespace|name triplet
An open-source system for automating deployment, scaling, and management of containerized applications.
The primary reference for [Software Catalog](#software-catalog) entities. It is human-readable and should be unique across your Backstage instance.
## Kubernetes (Backstage plugin)
A core Backstage plugin enabling a service owner-focused view of Kubernetes resources.
## Kubernetes (CNCF Project)
Kubernetes (K8s) is an open-source platform that automates the deployment, scaling, and management of containerized applications. Originally developed at Google to manage its production workloads, it was later offered to the [Cloud Native Computing Foundation (CNCF)](#cloud-native-computing-foundation-aka-cncf) for open-source support and maintenance.
According to its [official website](https://kubernetes.io/), Kubernetes automatically handles rollouts, rollbacks, and load balancing. It mounts storage systems, dynamically allocates containers based on resource requirements and other constraints, manages batch execution, restarts crashed containers, and more. For additional information, see the [Kubernetes article](https://en.wikipedia.org/wiki/Kubernetes) on Wikipedia.
## Local Package
One of the [packages](#package) within a [monorepo](#monorepo). A package may or may not also be published to a [package registry](#package-registry).
@@ -176,25 +210,31 @@ One of the [packages](#package) within a [monorepo](#monorepo). A package may or
2. A project layout that consists of multiple [packages](#package) within a single project, where packages are able to have local dependencies on each other. Often enabled through tooling such as [lerna](https://lerna.js.org/) and [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/)
## Name
To be completed. An element of the [kind|namespace|name triplet](#kind-namespace-name-triplet) that is an important concept for uniqueness.
## Namespace (catalog plugin)
An optional attribute that can be used to organize [entities](#entity).
## Objective
A high-level goal of a [user role](#User-Role) interacting with Backstage. Some goals of the _administrator_ user role, for example, are to maintain an instance ("app") of Backstage; to add and update functionality via plugins; and to troubleshoot issues.
An optional attribute that can be used to organize [entities](#entity). An element of the [kind|namespace|name triplet](#kind-namespace-name-triplet) that is an important concept for uniqueness.
## OAuth
Refers to: OAuth 2.0, a standard protocol and framework for granting third-party applications access to their data on other websites or services without sharing their passwords. See [oauth.net/2/](https://oauth.net/2/).
Refers to [OAuth 2.0](https://oauth.net/2/), an industry-standard authorization framework that allows a website or application (the "client") to access protected resources (like user data or functionality) on a different service (the "resource server") on behalf of a user (the "resource owner"), without sharing the user's login credentials with the client application.
See [OAuth 2.0 explained](https://connect2id.com/learn/oauth-2) for descriptions of OAuth 2.0 and [OIDC](#openid-connect-aka-oidc) (which is built on top of OAuth 2.0).
## Objective
A high-level goal of a [user role](#user-role) interacting with Backstage. For example, some objectives of the [administrator](#administrator) user role are to maintain an instance ([app](#app)) of Backstage, to add and update functionality via plugins, and to troubleshoot issues.
## Offline Access
[OAuth](#oauth) flow that results in both a refresh token and [access token](#access-token), where the refresh token has a long expiration or never expires, and can be used to request more access tokens in the future. This lets the user go "offline" with respect to the token issuer, but still be able to request more tokens at a later time without further direct interaction for the user.
[OAuth 2.0](https://oauth.net/2/) flow that results in both a [refresh token](#refresh-token) and an [access token](#access-token), where the refresh token has a long expiration or never expires, and can be used to request more access tokens in the future. This lets the user go "offline" with respect to the token issuer, but still be able to request more tokens at a later time without further direct interaction for the user.
## OpenID Connect
## OpenID Connect (aka OIDC)
A layer on top of [OAuth](#oauth) which standardises authentication. See [the Wikipedia article](https://en.wikipedia.org/wiki/OpenID_Connect) for more details.
A layer on top of [OAuth 2.0](https://oauth.net/2/) which standardises authentication. See [this Wikipedia article](https://en.wikipedia.org/wiki/OpenID_Connect) for details.
## OSS
@@ -202,7 +242,9 @@ Open source software.
## Package
A package in the Node.js ecosystem, often published to a [package registry](#package-registry).
1. A bundled collection of executable files, libraries, configuration files, metadata, and other necessary components that allow a piece of software (or a group of related software) to be easily installed, managed, and used. It's a standardized format for distributing software that simplifies installation by ensuring all dependencies are included or easily resolvable, provides integrity checks, and enables easy upgrades or removal.
2. A package in the Node.js ecosystem, often published to a [package registry](#package-registry).
## Package Registry
@@ -210,19 +252,23 @@ A service that hosts [packages](#package). The most prominent example is [NPM](h
## Package Role
The declared role of a package, see [package roles](../tooling/cli/02-build-system.md#package-roles).
The declared role of a package, see [package roles](https://backstage.io/docs/tooling/cli/build-system#package-roles).
## Permission
Specific rules or settings that define the level of access and types of actions that a user, group, or system process is allowed to perform on a particular resource. They are a core component of authorization that determine "what you can do" after you've been authenticated. Permissions are properties of objects or resources. Closely related to [Privilege](#privilege) (the terms are often used interchangeably).
## Permission (core Backstage plugin)
A core Backstage plugin and framework that allows restriction of actions to specific users. See [their docs](https://backstage.io/docs/permissions/overview) for more information.
Specific rules or settings that define the level of access and types of actions that a user, group, or system process is allowed to perform on a particular resource. Permissions are a core component of authorization that determine "what you can do" after you've been authenticated. Permissions are properties of objects or resources. Closely related to [Privilege](#privileges) (the terms are often used interchangeably).
## Permission (permission plugin)
A restriction on any action that a user can perform against a specific [resource](#resource-permission-plugin) or set of resources. See [the permission framework docs](../permissions/concepts.md#permission) for more details.
1. A core Backstage plugin and framework that allows actions to be limited to specific users.
2. A rule that determines whether a user is authorized to access a specific [resource](#resource-permission-plugin) or set of resources if a specified set of conditions exists.
By default, Backstage endpoints are unprotected; any user can perform any action on any resource. The Permission framework addresses this by enabling integrators to configure rules that specify precisely which users can access which resources and actions. Within this framework, a _permission_ is a uniquely named set of rules (or _conditions_) and the results to return based on their evaluation.
An example might be a permission rule that returns `false` if an entity is not part of a system, where the entity and system are configured for the rule. (See [Defining custom permission rules](https://backstage.io/docs/permissions/custom-rules) for the example.)
See the Permissions [Overview](https://backstage.io/docs/permissions/overview) and [Concepts](https://backstage.io/docs/permissions/concepts/) for details.
## Persona (use cases)
@@ -230,104 +276,141 @@ Alternative term for a [User Role](#user-role).
## Plugin
A module in Backstage that adds a feature. All functionality outside of [the Backstage framework](#backstage-framework), even the core features, are implemented as plugins.
The fundamental building block that adds specific features, functionalities, and integrations to your developer portal. All functionality outside of [the Backstage framework](#backstage-framework), even core features, are implemented as plugins. This modular architecture is a key differentiator of Backstage, making it highly customizable and extensible.
A plugin is a self-contained unit of code designed to perform a specific task or integrate with an external system. Instead of a monolithic application, Backstage is assembled from a collection of these independent plugins.
A single logical plugin often consists of both a frontend (UI) component and a backend (API) component.
- Frontend plugins are typically written in React and TypeScript to provide the user interface elements such as pages, cards, sidebar items, and dashboards that developers interact with.
- Backend plugin are written in Node.js and TypeScript, and handle data fetching, business logic, integrations with external services (like Git providers, CI/CD systems, and cloud platforms), and expose APIs for the frontend to consume.
There are different types of plugins (run `yarn new` to see them). The current list includes:
- `plugin` - A new frontend plugin
- `backend-plugin` - A new backend plugin
- `backend-module` - A new backend module
- `web-library` - A new web-library package
- `plugin-common` - A new isomorphic common plugin package
- `plugin-node` - A new `Node.js` library plugin package
- `plugin-react` - A new web library plugin package
See [Introduction to Plugins](https://backstage.io/docs/plugins/) for how to create a plugin, suggest a plugin, and integrate a plugin into the Software Catalog. See [Create a Backstage Plugin](https://backstage.io/docs/plugins/create-a-plugin/) for how to create a frontend plugin.
See [Plugin directory](https://backstage.io/plugins/) for a list of community driven plugins, although there is a community plugins repository that contains many more that might not be in that page.
## Policy (permission plugin)
A construct that takes in a Backstage user and a [permission](#permission-permission-plugin) and returns a [policy decision](#policy-decision-permission-plugin).
The central component of the Backstage permission framework that dictates who can do what, to which resources, and under what conditions.
Backstage policies are implemented as functions or sets of rules that receive a request (containing information about a user and a desired permission/action on a resource) and return an authorization decision (allow, deny, or a conditional decision). Policies are independent of the [authorization](#authorization) model, such as role-based access control or attribute-based access control. See [Policy](https://backstage.io/docs/permissions/concepts/#policy-permission-plugin).
Policies are defined in Typescript code in the permissions framework. See [Writing a permission policy](https://backstage.io/docs/permissions/writing-a-policy) for examples.
## Policy Decision (permission plugin)
A specific response to a user's request to perform an action on a list of [resources](#resource-permission-plugin). Can be either `Approve`, `Deny` or [`Conditional`](#conditional-decision-permission-plugin).
A specific response to a user's request to perform an action on a list of [resources](#resource-permission-plugin). Can be either `Approve`, `Deny` or `Conditional`. In Backstage, policies are only responsible for decisions regarding whether requests can be approved; the requestors (typically the backend) are responsible for enforcing those decisions. See [Policy decision versus enforcement](https://backstage.io/docs/permissions/concepts/#policy-decision-versus-enforcement).
## Popup
A separate browser window opened on top of the previous one.
A separate browser window that opens on top of the previous one.
## Privilege
## Privileges
Specific rules or settings that define what a user or process is allowed to do within the system, often relating to system-wide operations or capabilities. Privileges are properties of a subject, such as a user account or process, and represent a higher-level authority or right to perform certain security-critical functions. Closely related to [Permission](#permission) (the terms are often used interchangeably).
The term _privilege_ is not a defined abstraction in the context of the Backstage permission framework's core concepts. Instead, Backstage's authorization model is built around [permissions](#permission), [policies](#policy-permission-plugin), and [conditions](#condition-permission-plugin) to determine what actions a user can take on a resource. If you encounter _privilege_ in a Backstage context, it's likely being used in a more general, colloquial sense of "level of access" or referring to a concept.
Outside of Backstage contexts, _privilege_ typically refers to specific rules or settings that define what a user or process is allowed to do within the system, often relating to system-wide operations or capabilities. Privilege is closely related to [Permission](#permission); the terms are often used interchangeably.
## Procedure (use cases)
A set of actions that accomplish a goal, usually as part of a [use case](#Use-Case). A procedure can be high-level, containing other procedures, or can be as simple as a single [task](#Task).
A set of actions that accomplish a goal, usually as part of a [use case](#use-case). A procedure can be high-level, containing other procedures, or can be as simple as a single [task](#task-use-cases).
## Query Translators (search plugin)
An abstraction layer between a search engine and the [Backstage Search](#search) backend. Allows for translation into queries against your search engine.
An abstraction layer between a search engine and the [Backstage Search](#search) backend. It is an optional backend component that takes an abstract search query---which includes search terms, filters, and desired document types from a Backstage search client—--and transforms it into a concrete query that's optimized for a specific [Search Engine](#search-engine-backstage-search) used by Backstage.
This translation layer is crucial because it enables Backstage components to utilize the distinct features of individual search engines (like Elasticsearch or Solr) while maintaining loose coupling from their detailed interfaces. Although Backstage's pre-packaged Search Engines come with simple, built-in translators, you can implement custom Query Translators to significantly enhance and tune search results for your organization's unique context.
## Refresh token
A special token that an [OAuth](#oauth) client can use to get a new [access token](#access-token) when the latter expires. See [OAuth Refresh Tokens](https://oauth.net/2/refresh-tokens/) for details.
A special token that an [OAuth](#oauth) client can use to get a new [access token](#access-token) when the latter expires. See [OAuth Refresh Tokens](https://oauth.net/2/refresh-tokens/).
## Resource (catalog plugin)
An [entity](#entity) that represents a piece of physical or virtual infrastructure, for example a database, required by a component. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
An [entity](#entity) that represents a piece of physical or virtual infrastructure, such as a database, that's required by a component. See the [System Model](https://backstage.io/docs/features/software-catalog/system-model).
## Resource (permission plugin)
A representation of an object that a user interacts with and that can be permissioned. Not to be confused with [Software Catalog resources](#resource-catalog-plugin).
## Rule (permission plugin)
A predicate-based control that taps into a [resource](#resource-permission-plugin)'s data.
## Role
See [User Role](#User-Role).
See [User Role](#user-role).
## Rule (permission plugin)
A specific type of dynamic access control associated with a [resource](#resource-permission-plugin) it protects. A simple example might be "the current user can access Resource X if Condition Y is true." The catalog plugin defines a resource for catalog entities and rules to check if an entity has a given annotation.
## Scaffolder
Known as [Software Templates](#software-templates).
Another name for [Software Templates](#software-templates-aka-scaffolder). (The term comes from the use of Software Templates as _scaffolds_ for building new components and projects.)
## Scope
A string that describes a certain type of access that can be granted to a user using OAuth, usually in conjunction with [access tokens](#access-token).
A string that describes a certain type of access that can be granted to a user using [OAuth](#oauth), usually in conjunction with [access tokens](#access-token).
In [OAuth](#oauth), access control is managed through _scopes_ that define specific permissions granted to the application. An OAuth service can issue Access Tokens that are tied to particular sets of scopes, such as viewing profile information, or reading or writing user data. The format and handling of scopes are unique to each OAuth provider, with available scopes typically detailed in their authentication solution's documentation (see [https://developers.google.com/identity/protocols/oauth2/scopes](https://developers.google.com/identity/protocols/oauth2/scopes) for an example).
For more information about scopes and OAuth, see [OAuth and OpenID Connect](https://backstage.io/docs/auth/oauth/).
## Search
A Backstage plugin that provides a framework for searching a Backstage [app](#app), including the [Software Catalog](#Software-Catalog) and [TechDocs](#TechDocs). A core feature of Backstage.
A Backstage plugin that provides a framework for searching a Backstage [app](#app), including the [Software Catalog](#software-catalog) and [TechDocs](#techdocs). A core feature of Backstage.
## Search Engine (Backstage search)
Existing search technology that [Backstage Search](#search) can take advantage of through its modular design. Lunr is the default search in Backstage Search.
Existing search technology that [Backstage Search](#search) can take advantage of through its modular design. Lunr is the default search in Backstage Search. Can be one of the search engines that are pre-packaged with Backstage or chosen specifically for your instance.
## Software Catalog
A Backstage plugin that provides a framework to keep track of ownership and metadata for any number and type of software [components](#component). A core feature of Backstage.
1. A centralized system that keeps track of ownership and metadata for all software in your ecosystem (services, websites, libraries, data pipelines, etc.). The catalog is built around metadata YAML files that are stored with the code, and are harvested and visualized in Backstage.
## Software Templates
2. The Backstage plugin that implements the Software Catalog feature. A core feature of Backstage.
A Backstage plugin with which to create [components](#component) in Backstage. A core feature of Backstage. Also known as the scaffolder.
The Software Catalog is a core feature of Backstage. See [Backstage Software Catalog](https://backstage.io/docs/next/features/software-catalog/) for an overview, the life of an entity in the catalog, how to configure the catalog, its architecture and high-level design, how to configure and customize it, and its API. The overview describes how the catalog works, how to add components to it, how to find software in it, and more.
## Software Template
## Software Templates (aka Scaffolder)
A "skeleton" software project created and managed in the Backstage Software Templates tool.
1. A "skeleton" software project created and managed in the Backstage Software Templates tool.
2. A Backstage plugin for creating [components](#component-catalog-plugin) in Backstage. By default, it has the ability to load skeletons of code, template in some variables, and then publish the template to some locations like GitHub or GitLab.
Software Templates is a core feature of Backstage. It's also known as the [Scaffolder](#scaffolder) for its utility in building new software components and projects. See [Backstage Software Templates](https://backstage.io/docs/features/software-templates/) for an overview, how to configure it, add your own templates, write a template, test it, and more. The overview describes such information as how to get started, choose a template, verify your inputs, run the template, and see a demo.
## System (catalog plugin)
A collection of [entities](#entity) that cooperate to perform a function. A system generally provides one or a few public APIs and consists of a handful of components, resources, and private or public APIs. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
A collection of [entities](#entity) that cooperate to perform a function. A system generally consists of a handful of components, resources, and private or public APIs. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model).
## Task (use cases)
A low-level step-by-step [Procedure](#Procedure).
A low-level step-by-step [procedure](#procedure-use-cases) to achieve a particular result.
## TechDocs
A documentation solution that manages and generates technical documentation from Markdown files stored with software component code. A core feature of Backstage.
A documentation solution for generating and managing technical documentation in Markdown files that are stored with software component code. A core feature of Backstage. See [TechDocs Documentation](https://backstage.io/docs/features/techdocs/).
## Token
A string containing information.
A string containing information. The format and content depend on its purpose and how it's used.
## Use Case
A purpose for which a [user role](#User-Role) interacts with Backstage. Related to [Objective](#objective): An objective is _what_ the user wants to do, a use case is _how_ the user does it.
A purpose for which a [user role](#user-role) interacts with Backstage. Related to [Objective](#objective): An objective is _what_ a user wants to accomplish; a use case is _how_ the user does it.
## User
Any consumer of Backstage or Backstage products/applications. Includes individuals like employees and contractors, as well as software that interacts with the backend through an API or acts as a proxy for a person by operating the user interface.
Any consumer of Backstage or Backstage products/applications. This includes individuals like employees and contractors, as well as software that interacts with the backend through an API or acts as a proxy for a person by operating the user interface.
## User Role
A class of Backstage user for purposes of analyzing [use cases](#use-case). One of: [evaluator](#evaluator); [administrator](#administrator); [developer](#developer); [integrator](#integrator); and [contributor](#contributor).
A class of Backstage user who has permissions to use Backstage for a particular set of [use cases](#use-case). One of: [evaluator](#evaluator); [administrator](#administrator); [developer](#developer); [integrator](#integrator); and [contributor](#contributor).
+723
View File
@@ -0,0 +1,723 @@
# Release v1.42.0-next.2
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.42.0-next.2](https://backstage.github.io/upgrade-helper/?to=1.42.0-next.2)
## @backstage/cli@0.34.0-next.1
### Minor Changes
- 38b4243: Added plugin and module templates for the new frontend system. These templates are not included by default, but can be included by adding `@backstage/cli/templates/new-frontend-plugin` and `@backstage/cli/templates/new-frontend-plugin-module` as [custom templates](https://backstage.io/docs/tooling/cli/templates#installing-custom-templates).
### Patch Changes
- Updated dependencies
- @backstage/catalog-model@1.7.5
- @backstage/cli-common@0.1.15
- @backstage/cli-node@0.2.13
- @backstage/config@1.3.3
- @backstage/config-loader@1.10.2
- @backstage/errors@1.2.7
- @backstage/eslint-plugin@0.1.11
- @backstage/integration@1.17.1
- @backstage/release-manifests@0.0.13
- @backstage/types@1.2.1
## @backstage/core-compat-api@0.5.0-next.2
### Minor Changes
- e4ddf22: **BREAKING**: The `defaultPath` override of `convertLegacyPageExtension` has been renamed to `path`, in order to align with the same update that was made to the `PageBlueprint`.
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- 5d31d66: Updated the usage of the `RouterBlueprint` and `AppRootWrapperBlueprint` to use the lowercase `component` parameter
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-plugin-api@1.10.9
- @backstage/version-bridge@1.0.11
## @backstage/frontend-app-api@0.12.0-next.2
### Minor Changes
- df7bd3b: **BREAKING**: Removed the deprecated `FrontendFeature` type, import it from `@backstage/frontend-plugin-api` instead.
### Patch Changes
- d9e00e3: Add support for a new `aliasFor` option for `createRouteRef`. This allows for the creation of a new route ref that acts as an alias for an existing route ref that is installed in the app. This is particularly useful when creating modules that override existing plugin pages, without referring to the existing plugin. For example:
```tsx
export default createFrontendModule({
pluginId: 'catalog',
extensions: [
PageBlueprint.make({
params: {
defaultPath: '/catalog',
routeRef: createRouteRef({ aliasFor: 'catalog.catalogIndex' }),
loader: () =>
import('./CustomCatalogIndexPage').then(m => (
<m.CustomCatalogIndexPage />
)),
},
}),
],
});
```
- 3d2499f: Moved `createSpecializedApp` options to a new `CreateSpecializedAppOptions` type.
- Updated dependencies
- @backstage/frontend-defaults@0.3.0-next.2
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
## @backstage/frontend-defaults@0.3.0-next.2
### Minor Changes
- 76832a9: **BREAKING**: Removed the deprecated `CreateAppFeatureLoader` and support for it in other APIs. Switch existing usage to use the newer `createFrontendFeatureLoader` from `@backstage/frontend-plugin-api` instead.
### Patch Changes
- 22de964: Deprecated `createPublicSignInApp`, which has been replaced by the new `appModulePublicSignIn` from `@backstage/plugin-app/alpha` instead.
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/frontend-app-api@0.12.0-next.2
- @backstage/plugin-app@0.2.0-next.1
- @backstage/config@1.3.3
- @backstage/errors@1.2.7
## @backstage/frontend-plugin-api@0.11.0-next.1
### Minor Changes
- c5f88b5: **BREAKING**: Remove deprecated `source` property from the `AppNodeSpec` type, use `AppNodeSpec.plugin` instead.
- e4ddf22: **BREAKING**: The `defaultPath` param of `PageBlueprint` has been renamed to `path`. This change does not affect the compatibility of extensions created with older versions of this blueprint.
- 37f2989: **BREAKING**: Removed the `routable` property from `ExtensionBoundary`. This property was never needed in practice and is instead inferred from whether or not the extension outputs a route reference. It can be safely removed.
- 3243fa6: **BREAKING**: Removed the ability to define a default extension `name` in blueprints. This option had no practical purpose as blueprints already use the `kind` to identity the source of the extension.
- a082429: **BREAKING**: The separate `RouteResolutionApiResolveOptions` type has been removed.
- 5d31d66: **BREAKING**: In an attempt to align some of the API's around providing components to `Blueprints`, we've renamed the parameters for both the `RouterBlueprint` and `AppRootWrapperBlueprint` from `Component` to `component`.
```tsx
// old
RouterBlueprint.make({
params: {
Component: ({ children }) => <div>{children}</div>,
},
});
// new
RouterBlueprint.make({
params: {
component: ({ children }) => <div>{children}</div>,
},
});
```
```tsx
// old
AppRootWrapperBlueprint.make({
params: {
Component: ({ children }) => <div>{children}</div>,
},
});
// new
AppRootWrapperBlueprint.make({
params: {
component: ({ children }) => <div>{children}</div>,
},
});
```
As part of this change, the type for `component` has also changed from `ComponentType<PropsWithChildren<{}>>` to `(props: { children: ReactNode }) => JSX.Element | null` which is not breaking, just a little more reflective of the actual expected component.
- 45ead4a: **BREAKING**: The `AnyRoutes` and `AnyExternalRoutes` types have been removed and their usage has been inlined instead.
Existing usage can be replaced according to their previous definitions:
```ts
type AnyRoutes = { [name in string]: RouteRef | SubRouteRef };
type AnyExternalRoutes = { [name in string]: ExternalRouteRef };
```
- 121899a: **BREAKING**: The `element` param for `AppRootElementBlueprint` no longer accepts a component. If you are currently passing a component such as `element: () => <MyComponent />` or `element: MyComponent`, simply switch to `element: <MyComponent />`.
- a321f3b: **BREAKING**: The `CommonAnalyticsContext` has been removed, and inlined into `AnalyticsContextValue` instead.
### Patch Changes
- d9e00e3: Add support for a new `aliasFor` option for `createRouteRef`. This allows for the creation of a new route ref that acts as an alias for an existing route ref that is installed in the app. This is particularly useful when creating modules that override existing plugin pages, without referring to the existing plugin. For example:
```tsx
export default createFrontendModule({
pluginId: 'catalog',
extensions: [
PageBlueprint.make({
params: {
defaultPath: '/catalog',
routeRef: createRouteRef({ aliasFor: 'catalog.catalogIndex' }),
loader: () =>
import('./CustomCatalogIndexPage').then(m => (
<m.CustomCatalogIndexPage />
)),
},
}),
],
});
```
- 93b5e38: Plugins should now use the new `AnalyticsImplementationBlueprint` to define and provide concrete analytics implementations. For example:
```ts
import { AnalyticsImplementationBlueprint } from '@backstage/frontend-plugin-api';
const AcmeAnalytics = AnalyticsImplementationBlueprint.make({
name: 'acme-analytics',
params: define =>
define({
deps: { config: configApiRef },
factory: ({ config }) => AcmeAnalyticsImpl.fromConfig(config),
}),
});
```
- 948de17: Tweaked the return types from `createExtension` and `createExtensionBlueprint` to avoid the forwarding of `ConfigurableExtensionDataRef` into exported types.
- 147482b: Updated the recommended naming of the blueprint param callback from `define` to `defineParams`, making the syntax `defineParams => defineParams(...)`.
- 3c3c882: Added added defaults for all type parameters of `ExtensionDataRef` and deprecated `AnyExtensionDataRef`, as it is now redundant.
- Updated dependencies
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
## @backstage/plugin-app@0.2.0-next.1
### Minor Changes
- 121899a: **BREAKING**: The `app-root-element` extension now only accepts `JSX.Element` in its `element` param, meaning overrides need to be updated.
### Patch Changes
- a08f95f: Added a new module for implementing public sign-in apps, exported as `appModulePublicSignIn` via the `/alpha` sub-path export. This replaces the `createPublicSignInApp` export from `@backstage/frontend-defaults`, which is now deprecated.
- 5d31d66: Updated the usage of the `RouterBlueprint` and `AppRootWrapperBlueprint` to use the lowercase `component` parameter
- 93b5e38: The default implementation of the Analytics API now collects and instantiates analytics implementations exposed via `AnalyticsImplementationBlueprint` extensions. If no such extensions are discovered, the API continues to do nothing with analytics events fired within Backstage. If multiple such extensions are discovered, every discovered implementation automatically receives analytics events.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/integration-react@1.2.9
- @backstage/theme@0.6.8-next.0
- @backstage/types@1.2.1
- @backstage/plugin-permission-react@0.4.36
## @backstage/plugin-catalog-react@1.20.0-next.2
### Minor Changes
- e4ddf22: **BREAKING ALPHA**: The `defaultPath`, `defaultTitle`, and `defaultGroup` params of `PageBlueprint` has been renamed to `path`, `title`, and `group`. The `convertLegacyEntityContentExtension` utility has also received the same change. This change does not affect the compatibility of extensions created with older versions of this blueprint.
### Patch Changes
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/frontend-test-utils@0.3.5-next.2
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/integration-react@1.2.9
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-permission-common@0.9.1
- @backstage/plugin-permission-react@0.4.36
## @backstage/core-components@0.17.5-next.1
### Patch Changes
- 5563605: Added `FavoriteToggleProps`.
- Updated dependencies
- @backstage/config@1.3.3
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/theme@0.6.8-next.0
- @backstage/version-bridge@1.0.11
## @backstage/create-app@0.7.2-next.2
### Patch Changes
- Bumped create-app version.
- Updated dependencies
- @backstage/cli-common@0.1.15
## @backstage/frontend-test-utils@0.3.5-next.2
### Patch Changes
- df7bd3b: Updated import of the `FrontendFeature` type.
- 5d31d66: Updated the usage of the `RouterBlueprint` and `AppRootWrapperBlueprint` to use the lowercase `component` parameter
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/frontend-app-api@0.12.0-next.2
- @backstage/plugin-app@0.2.0-next.1
- @backstage/config@1.3.3
- @backstage/test-utils@1.7.11-next.0
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
## @backstage/ui@0.7.0-next.2
### Patch Changes
- d4e603e: Updated Menu component in Backstage UI to use useId() from React Aria instead of React to support React 17.
## @backstage/plugin-api-docs@0.12.10-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog@1.31.2-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-permission-react@0.4.36
## @backstage/plugin-app-visualizer@0.1.22-next.1
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
## @backstage/plugin-catalog@1.31.2-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/integration-react@1.2.9
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-permission-react@0.4.36
- @backstage/plugin-scaffolder-common@1.7.0-next.0
- @backstage/plugin-search-common@1.2.19
- @backstage/plugin-techdocs-common@0.1.1
- @backstage/plugin-techdocs-react@1.3.2-next.0
## @backstage/plugin-catalog-graph@0.4.22-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/types@1.2.1
## @backstage/plugin-catalog-import@0.13.4-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/integration@1.17.1
- @backstage/integration-react@1.2.9
- @backstage/plugin-catalog-common@1.1.5
## @backstage/plugin-catalog-unprocessed-entities@0.2.20-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
## @backstage/plugin-devtools@0.1.30-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/plugin-devtools-common@0.1.17
- @backstage/plugin-permission-react@0.4.36
## @backstage/plugin-home@0.8.11-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- 121899a: **BREAKING ALPHA**: The `app-root-element` extension now only accepts `JSX.Element` in its `element` param, meaning overrides need to be updated.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-home-react@0.1.29-next.0
## @backstage/plugin-kubernetes@0.12.10-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/plugin-kubernetes-common@0.9.6
- @backstage/plugin-kubernetes-react@0.5.10-next.0
- @backstage/plugin-permission-react@0.4.36
## @backstage/plugin-notifications@0.5.8-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/theme@0.6.8-next.0
- @backstage/types@1.2.1
- @backstage/plugin-notifications-common@0.0.10
- @backstage/plugin-signals-react@0.0.15
## @backstage/plugin-org@0.6.42-next.2
### Patch Changes
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/plugin-catalog-common@1.1.5
## @backstage/plugin-scaffolder@1.34.0-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/integration@1.17.1
- @backstage/integration-react@1.2.9
- @backstage/types@1.2.1
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-permission-react@0.4.36
- @backstage/plugin-scaffolder-common@1.7.0-next.0
- @backstage/plugin-scaffolder-react@1.19.0-next.1
## @backstage/plugin-search@1.4.29-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
- @backstage/plugin-search-common@1.2.19
## @backstage/plugin-search-backend-module-catalog@0.3.7-next.1
### Patch Changes
- d9bda0f: Allow filter to be an array in config schema
- Updated dependencies
- @backstage/backend-plugin-api@1.4.2-next.0
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/errors@1.2.7
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-catalog-node@1.18.0-next.0
- @backstage/plugin-permission-common@0.9.1
- @backstage/plugin-search-backend-node@1.3.14-next.0
- @backstage/plugin-search-common@1.2.19
## @backstage/plugin-search-react@1.9.3-next.1
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/theme@0.6.8-next.0
- @backstage/types@1.2.1
- @backstage/version-bridge@1.0.11
- @backstage/plugin-search-common@1.2.19
## @backstage/plugin-signals@0.0.22-next.2
### Patch Changes
- 121899a: **BREAKING ALPHA**: The `app-root-element` extension now only accepts `JSX.Element` in its `element` param, meaning overrides need to be updated.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/core-plugin-api@1.10.9
- @backstage/theme@0.6.8-next.0
- @backstage/types@1.2.1
- @backstage/plugin-signals-react@0.0.15
## @backstage/plugin-techdocs@1.14.0-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/integration@1.17.1
- @backstage/integration-react@1.2.9
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-auth-react@0.1.18-next.0
- @backstage/plugin-search-common@1.2.19
- @backstage/plugin-techdocs-common@0.1.1
- @backstage/plugin-techdocs-react@1.3.2-next.0
## @backstage/plugin-techdocs-backend@2.0.5-next.1
### Patch Changes
- 484e500: Updated CachedEntityLoader to use BackstageCredentials instead of raw tokens for cache key generation. It now uses principal-based identification (user entity ref for users, subject for services) instead of token-based keys, providing more consistent caching behavior.
- Updated dependencies
- @backstage/backend-defaults@0.11.2-next.0
- @backstage/backend-plugin-api@1.4.2-next.0
- @backstage/catalog-client@1.11.0-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/errors@1.2.7
- @backstage/integration@1.17.1
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-catalog-node@1.18.0-next.0
- @backstage/plugin-permission-common@0.9.1
- @backstage/plugin-search-backend-module-techdocs@0.4.5-next.0
- @backstage/plugin-techdocs-common@0.1.1
- @backstage/plugin-techdocs-node@1.13.6-next.0
## @backstage/plugin-user-settings@0.8.25-next.2
### Patch Changes
- e4ddf22: Internal update to align with new blueprint parameter naming in the new frontend system.
- Updated dependencies
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/catalog-model@1.7.5
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/errors@1.2.7
- @backstage/theme@0.6.8-next.0
- @backstage/types@1.2.1
- @backstage/plugin-signals-react@0.0.15
- @backstage/plugin-user-settings-common@0.0.1
## example-app@0.2.112-next.2
### Patch Changes
- Updated dependencies
- @backstage/frontend-app-api@0.12.0-next.2
- @backstage/cli@0.34.0-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.20-next.2
- @backstage/plugin-catalog-import@0.13.4-next.2
- @backstage/plugin-catalog-graph@0.4.22-next.2
- @backstage/plugin-notifications@0.5.8-next.2
- @backstage/plugin-user-settings@0.8.25-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-kubernetes@0.12.10-next.2
- @backstage/plugin-scaffolder@1.34.0-next.2
- @backstage/plugin-api-docs@0.12.10-next.2
- @backstage/plugin-devtools@0.1.30-next.2
- @backstage/plugin-techdocs@1.14.0-next.2
- @backstage/plugin-catalog@1.31.2-next.2
- @backstage/plugin-search@1.4.29-next.2
- @backstage/plugin-home@0.8.11-next.2
- @backstage/ui@0.7.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/plugin-signals@0.0.22-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/app-defaults@1.6.5-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/integration-react@1.2.9
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-auth-react@0.1.18-next.0
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-kubernetes-cluster@0.0.28-next.1
- @backstage/plugin-org@0.6.42-next.2
- @backstage/plugin-permission-react@0.4.36
- @backstage/plugin-scaffolder-react@1.19.0-next.1
- @backstage/plugin-search-common@1.2.19
- @backstage/plugin-techdocs-module-addons-contrib@1.1.27-next.0
- @backstage/plugin-techdocs-react@1.3.2-next.0
## example-app-next@0.0.26-next.2
### Patch Changes
- Updated dependencies
- @backstage/frontend-defaults@0.3.0-next.2
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/frontend-app-api@0.12.0-next.2
- @backstage/cli@0.34.0-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.20-next.2
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-app-visualizer@0.1.22-next.1
- @backstage/plugin-catalog-import@0.13.4-next.2
- @backstage/plugin-catalog-graph@0.4.22-next.2
- @backstage/plugin-notifications@0.5.8-next.2
- @backstage/plugin-user-settings@0.8.25-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-kubernetes@0.12.10-next.2
- @backstage/plugin-scaffolder@1.34.0-next.2
- @backstage/plugin-api-docs@0.12.10-next.2
- @backstage/plugin-techdocs@1.14.0-next.2
- @backstage/plugin-catalog@1.31.2-next.2
- @backstage/plugin-search@1.4.29-next.2
- @backstage/plugin-home@0.8.11-next.2
- @backstage/plugin-app@0.2.0-next.1
- @backstage/ui@0.7.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/plugin-signals@0.0.22-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/app-defaults@1.6.5-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/integration-react@1.2.9
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-auth-react@0.1.18-next.0
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-kubernetes-cluster@0.0.28-next.1
- @backstage/plugin-org@0.6.42-next.2
- @backstage/plugin-permission-react@0.4.36
- @backstage/plugin-scaffolder-react@1.19.0-next.1
- @backstage/plugin-search-common@1.2.19
- @backstage/plugin-techdocs-module-addons-contrib@1.1.27-next.0
- @backstage/plugin-techdocs-react@1.3.2-next.0
## techdocs-cli-embedded-app@0.2.111-next.2
### Patch Changes
- Updated dependencies
- @backstage/cli@0.34.0-next.1
- @backstage/plugin-techdocs@1.14.0-next.2
- @backstage/plugin-catalog@1.31.2-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/app-defaults@1.6.5-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/integration-react@1.2.9
- @backstage/test-utils@1.7.11-next.0
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-techdocs-react@1.3.2-next.0
@@ -3,8 +3,8 @@ title: 'Analytics Module: Google Analytics'
author: Spotify
authorUrl: https://github.com/spotify
category: Monitoring
description: Track usage of your Backstage instance using Google Analytics.
documentation: https://github.com/backstage/community-plugins/blob/main/workspaces/analytics/plugins/analytics-module-ga/README.md
description: Track usage of your Backstage instance using Google Analytics 4.
documentation: https://github.com/backstage/community-plugins/tree/main/workspaces/analytics/plugins/analytics-module-ga4#readme
iconUrl: /img/ga-icon.png
npmPackageName: '@backstage/plugin-analytics-module-ga'
npmPackageName: '@backstage/plugin-analytics-module-ga4'
addedDate: '2021-10-07'
+73 -12
View File
@@ -5353,7 +5353,7 @@ __metadata:
languageName: node
linkType: hard
"create-hash@npm:^1.1.0, create-hash@npm:^1.1.2, create-hash@npm:^1.2.0":
"create-hash@npm:^1.1.0, create-hash@npm:^1.2.0":
version: 1.2.0
resolution: "create-hash@npm:1.2.0"
dependencies:
@@ -5366,7 +5366,19 @@ __metadata:
languageName: node
linkType: hard
"create-hmac@npm:^1.1.4, create-hmac@npm:^1.1.7":
"create-hash@npm:~1.1.3":
version: 1.1.3
resolution: "create-hash@npm:1.1.3"
dependencies:
cipher-base: "npm:^1.0.1"
inherits: "npm:^2.0.1"
ripemd160: "npm:^2.0.0"
sha.js: "npm:^2.4.0"
checksum: 10/b9f675719321dd3a3c3540bb46afcbdaf7182366ce93da9265318290e928be881e5edeff8c48a5ee9263c342e5e3f705fad5eb48f2e2cddc5fed1eb54077e076
languageName: node
linkType: hard
"create-hmac@npm:^1.1.7":
version: 1.1.7
resolution: "create-hmac@npm:1.1.7"
dependencies:
@@ -7288,6 +7300,15 @@ __metadata:
languageName: node
linkType: hard
"hash-base@npm:^2.0.0":
version: 2.0.2
resolution: "hash-base@npm:2.0.2"
dependencies:
inherits: "npm:^2.0.1"
checksum: 10/e39f3f2bb91679ed350bd2eb81035acb1e1e6e9bb86d9f1197fcfdc3cf39a2c56bf82a1870f000fae651477883b4c107fd6ac0c640a18ab06298b87c39939396
languageName: node
linkType: hard
"hash-base@npm:^3.0.0":
version: 3.1.0
resolution: "hash-base@npm:3.1.0"
@@ -8327,7 +8348,7 @@ __metadata:
languageName: node
linkType: hard
"is-typed-array@npm:^1.1.3":
"is-typed-array@npm:^1.1.14, is-typed-array@npm:^1.1.3":
version: 1.1.15
resolution: "is-typed-array@npm:1.1.15"
dependencies:
@@ -8366,6 +8387,13 @@ __metadata:
languageName: node
linkType: hard
"isarray@npm:^2.0.5":
version: 2.0.5
resolution: "isarray@npm:2.0.5"
checksum: 10/1d8bc7911e13bb9f105b1b3e0b396c787a9e63046af0b8fe0ab1414488ab06b2b099b87a2d8a9e31d21c9a6fad773c7fc8b257c4880f2d957274479d28ca3414
languageName: node
linkType: hard
"isarray@npm:~1.0.0":
version: 1.0.0
resolution: "isarray@npm:1.0.0"
@@ -11289,15 +11317,16 @@ __metadata:
linkType: hard
"pbkdf2@npm:^3.1.2":
version: 3.1.2
resolution: "pbkdf2@npm:3.1.2"
version: 3.1.3
resolution: "pbkdf2@npm:3.1.3"
dependencies:
create-hash: "npm:^1.1.2"
create-hmac: "npm:^1.1.4"
ripemd160: "npm:^2.0.1"
safe-buffer: "npm:^5.0.1"
sha.js: "npm:^2.4.8"
checksum: 10/40bdf30df1c9bb1ae41ec50c11e480cf0d36484b7c7933bf55e4451d1d0e3f09589df70935c56e7fccc5702779a0d7b842d012be8c08a187b44eb24d55bb9460
create-hash: "npm:~1.1.3"
create-hmac: "npm:^1.1.7"
ripemd160: "npm:=2.0.1"
safe-buffer: "npm:^5.2.1"
sha.js: "npm:^2.4.11"
to-buffer: "npm:^1.2.0"
checksum: 10/980cf2977aa84ec3166fde195a28464ab494131c0a5778fc8f20b8894410747e502159c19ef2b41842c728bc52ba49ffee6847e3ee61ac0d482689f85d8a1b30
languageName: node
linkType: hard
@@ -12876,6 +12905,16 @@ __metadata:
languageName: node
linkType: hard
"ripemd160@npm:=2.0.1":
version: 2.0.1
resolution: "ripemd160@npm:2.0.1"
dependencies:
hash-base: "npm:^2.0.0"
inherits: "npm:^2.0.1"
checksum: 10/f1a20b72b3ef897a981544c72a1fe15c2bd580f6f40e3062f7839af8e81232f746aa860964686e4b81e90929ad086f14823a9864e4e4bed3367e597fe14a0968
languageName: node
linkType: hard
"ripemd160@npm:^2.0.0, ripemd160@npm:^2.0.1":
version: 2.0.2
resolution: "ripemd160@npm:2.0.2"
@@ -13243,7 +13282,7 @@ __metadata:
languageName: node
linkType: hard
"sha.js@npm:^2.4.0, sha.js@npm:^2.4.8":
"sha.js@npm:^2.4.0, sha.js@npm:^2.4.11, sha.js@npm:^2.4.8":
version: 2.4.11
resolution: "sha.js@npm:2.4.11"
dependencies:
@@ -14041,6 +14080,17 @@ __metadata:
languageName: node
linkType: hard
"to-buffer@npm:^1.2.0":
version: 1.2.1
resolution: "to-buffer@npm:1.2.1"
dependencies:
isarray: "npm:^2.0.5"
safe-buffer: "npm:^5.2.1"
typed-array-buffer: "npm:^1.0.3"
checksum: 10/f8d03f070b8567d9c949f1b59c8d47c83ed2e59b50b5449258f931df9a1fcb751aa8bb8756a9345adc529b6b1822521157c48e1a7d01779a47185060d7bf96d4
languageName: node
linkType: hard
"to-fast-properties@npm:^2.0.0":
version: 2.0.0
resolution: "to-fast-properties@npm:2.0.0"
@@ -14144,6 +14194,17 @@ __metadata:
languageName: node
linkType: hard
"typed-array-buffer@npm:^1.0.3":
version: 1.0.3
resolution: "typed-array-buffer@npm:1.0.3"
dependencies:
call-bound: "npm:^1.0.3"
es-errors: "npm:^1.3.0"
is-typed-array: "npm:^1.1.14"
checksum: 10/3fb91f0735fb413b2bbaaca9fabe7b8fc14a3fa5a5a7546bab8a57e755be0e3788d893195ad9c2b842620592de0e68d4c077d4c2c41f04ec25b8b5bb82fa9a80
languageName: node
linkType: hard
"typedarray-to-buffer@npm:^3.1.5":
version: 3.1.5
resolution: "typedarray-to-buffer@npm:3.1.5"
+2 -2
View File
@@ -1,6 +1,6 @@
{
"name": "root",
"version": "1.42.0-next.1",
"version": "1.42.0-next.2",
"backstage": {
"cli": {
"new": {
@@ -154,7 +154,7 @@
"sloc": "^0.3.1",
"sort-package-json": "^2.8.0",
"typedoc": "^0.28.0",
"typescript": "~5.6.0"
"typescript": "~5.7.0"
},
"packageManager": "yarn@4.8.1",
"engines": {
@@ -4,7 +4,7 @@
```ts
import { AnyRouteRefParams } from '@backstage/frontend-plugin-api';
import { ConfigurableExtensionDataRef } from '@backstage/frontend-plugin-api';
import { ExtensionDataRef } from '@backstage/frontend-plugin-api';
import { ExtensionDefinition } from '@backstage/frontend-plugin-api';
import { FrontendPlugin } from '@backstage/frontend-plugin-api';
import { JSX as JSX_2 } from 'react';
@@ -26,9 +26,9 @@ const examplePlugin: FrontendPlugin<
path?: string | undefined;
};
output:
| ConfigurableExtensionDataRef<JSX_2.Element, 'core.reactElement', {}>
| ConfigurableExtensionDataRef<string, 'core.routing.path', {}>
| ConfigurableExtensionDataRef<
| ExtensionDataRef<string, 'core.routing.path', {}>
| ExtensionDataRef<JSX_2.Element, 'core.reactElement', {}>
| ExtensionDataRef<
RouteRef<AnyRouteRefParams>,
'core.routing.ref',
{
@@ -37,7 +37,8 @@ const examplePlugin: FrontendPlugin<
>;
inputs: {};
params: {
defaultPath: string;
defaultPath?: [Error: `Use the 'path' param instead`];
path: string;
loader: () => Promise<JSX.Element>;
routeRef?: RouteRef;
};
@@ -21,7 +21,7 @@ import {
export const ExamplePage = PageBlueprint.make({
params: {
defaultPath: '/example',
path: '/example',
loader: () => import('./Component').then(m => <m.Component />),
},
});
+46
View File
@@ -1,5 +1,51 @@
# example-app-next
## 0.0.26-next.2
### Patch Changes
- Updated dependencies
- @backstage/frontend-defaults@0.3.0-next.2
- @backstage/frontend-plugin-api@0.11.0-next.1
- @backstage/frontend-app-api@0.12.0-next.2
- @backstage/cli@0.34.0-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.20-next.2
- @backstage/core-compat-api@0.5.0-next.2
- @backstage/plugin-app-visualizer@0.1.22-next.1
- @backstage/plugin-catalog-import@0.13.4-next.2
- @backstage/plugin-catalog-graph@0.4.22-next.2
- @backstage/plugin-notifications@0.5.8-next.2
- @backstage/plugin-user-settings@0.8.25-next.2
- @backstage/plugin-search-react@1.9.3-next.1
- @backstage/plugin-kubernetes@0.12.10-next.2
- @backstage/plugin-scaffolder@1.34.0-next.2
- @backstage/plugin-api-docs@0.12.10-next.2
- @backstage/plugin-techdocs@1.14.0-next.2
- @backstage/plugin-catalog@1.31.2-next.2
- @backstage/plugin-search@1.4.29-next.2
- @backstage/plugin-home@0.8.11-next.2
- @backstage/plugin-app@0.2.0-next.1
- @backstage/ui@0.7.0-next.2
- @backstage/plugin-catalog-react@1.20.0-next.2
- @backstage/plugin-signals@0.0.22-next.2
- @backstage/core-components@0.17.5-next.1
- @backstage/app-defaults@1.6.5-next.0
- @backstage/catalog-model@1.7.5
- @backstage/config@1.3.3
- @backstage/core-app-api@1.18.0
- @backstage/core-plugin-api@1.10.9
- @backstage/integration-react@1.2.9
- @backstage/theme@0.6.8-next.0
- @backstage/plugin-auth-react@0.1.18-next.0
- @backstage/plugin-catalog-common@1.1.5
- @backstage/plugin-kubernetes-cluster@0.0.28-next.1
- @backstage/plugin-org@0.6.42-next.2
- @backstage/plugin-permission-react@0.4.36
- @backstage/plugin-scaffolder-react@1.19.0-next.1
- @backstage/plugin-search-common@1.2.19
- @backstage/plugin-techdocs-module-addons-contrib@1.1.27-next.0
- @backstage/plugin-techdocs-react@1.3.2-next.0
## 0.0.26-next.1
### Patch Changes
+1 -2
View File
@@ -1,6 +1,5 @@
app:
experimental:
packages: 'all' # ✨
packages: 'all' # ✨
routes:
bindings:
+1 -5
View File
@@ -1,6 +1,6 @@
# Knip report
## Unused dependencies (30)
## Unused dependencies (26)
| Name | Location | Severity |
| :----------------------------------------------- | :----------- | :------- |
@@ -12,19 +12,15 @@
| @backstage/plugin-catalog-common | package.json | error |
| @backstage/plugin-techdocs-react | package.json | error |
| @backstage/plugin-catalog-graph | package.json | error |
| @backstage/plugin-notifications | package.json | error |
| @backstage/plugin-search-common | package.json | error |
| @backstage/plugin-search-react | package.json | error |
| @backstage/integration-react | package.json | error |
| @backstage/plugin-auth-react | package.json | error |
| @backstage/plugin-scaffolder | package.json | error |
| @backstage/frontend-app-api | package.json | error |
| @backstage/core-plugin-api | package.json | error |
| @backstage/plugin-api-docs | package.json | error |
| @backstage/plugin-catalog | package.json | error |
| @backstage/plugin-signals | package.json | error |
| @backstage/catalog-model | package.json | error |
| @backstage/plugin-search | package.json | error |
| @backstage/app-defaults | package.json | error |
| @backstage/plugin-app | package.json | error |
| @backstage/plugin-org | package.json | error |

Some files were not shown because too many files have changed in this diff Show More