From 7aa11037e959298e5872db0cf9c9acf3b34e01ff Mon Sep 17 00:00:00 2001 From: Patrik Oldsberg Date: Wed, 5 Jun 2024 16:09:32 +0200 Subject: [PATCH] beps/0009: add alternative library format Signed-off-by: Patrik Oldsberg --- beps/0009-plugin-metadata/README.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/beps/0009-plugin-metadata/README.md b/beps/0009-plugin-metadata/README.md index c8820d411e..22a2468d35 100644 --- a/beps/0009-plugin-metadata/README.md +++ b/beps/0009-plugin-metadata/README.md @@ -163,6 +163,35 @@ None ## Alternatives +### Simplified Library Relationships + +Rather than listing libraries for each role, we could simply have an array of libraries that are available for the plugin: + +```json +{ + "name": "@backstage/plugin-catalog", + "backstage": { + "role": "frontend-plugin", + "pluginId": "catalog", + "pluginPackages": { + "frontend-plugin": "@backstage/plugin-catalog", + "backend-plugin": "@backstage/plugin-catalog-backend", + "libraries": [ + "@backstage/plugin-catalog-react", + "@backstage/plugin-catalog-node", + "@backstage/plugin-catalog-common" + ] + } + } +} +``` + +A benefit of this approach is that it keeps the metadata simpler and reduces the need for conflict resolution logic since we can use the union of all listed library packages. + +It also allows for the use-case of having multiple libraries of the same role, in case that would provide a benefit. Examples of this are the `@backstage/catalog-client` and `@backstage/catalog-model` packages. + +A downside of this approach could be that it may encourage a larger number of library packages, which is not necessarily what we want. Another downside is that the role of each package is not immediately available. + ### Separate Metadata File This proposal suggests that we keep metadata in the `package.json` file. An alternative would be to define a separate metadata file, for example `backstage.json` or `backstage.yaml`.