docs/tooling/package-metadata: add docs for backstage.features

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
Patrik Oldsberg
2025-09-30 11:21:48 +02:00
parent 6ee65a9deb
commit bdef1e2254
+26
View File
@@ -96,6 +96,32 @@ This field can be generated by the `backstage-cli repo fix --publish` command. T
The presence of this field is checked by the `backstage-cli package prepack` command, which is used to prepare a package for publishing. You can read more about this requirement in the section on [metadata for published packages](#metadata-for-published-packages).
### `backstage.features`
This field declares where to find Backstage features exported from the package. It is a map of features export paths to their feature type, similar to the `exports` field.
```js title="Example usage of the backstage.features field"
{
"name": "@backstage/plugin-catalog",
"backstage": {
"features": {
"./alpha": "@backstage/FrontendPlugin"
}
}
}
```
This field is automatically generated by the `backstage-cli package prepack` command when publishing a package and therefore does not need to be committed to the repository.
If you are using your own tooling to publish a package, you need to populate this field manually, using the following feature types:
- `@backstage/BackendFeature`
- `@backstage/FrontendPlugin`
- `@backstage/FrontendModule`
- `@backstage/FrontendFeatureLoader`
You can read more about the feature types in the [backend system](../backend-system/architecture/01-index.md) and [frontend system](../frontend-system/architecture/00-index.md) documentation.
### `backstage.pluginPackages`
For any package that is part of a plugin, this field should be set to a list of all packages that are directly part of the same plugin. This includes frontend and backend plugin packages as well as related libraries, but not modules.