Merge branch 'master' into runtime-module-federation-enablement

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/tooling/cli/03-commands.md

@@ -287,7 +287,7 @@ it is possible to pre-select what you want to create using the `--select` flag,
 and provide options using `--option`, for example:
 
 ```bash
-backstage-cli new --select plugin --option pluginId=foo
+backstage-cli new --select frontend-plugin --option pluginId=foo
 ```
 
 This command is typically added as script in the root `package.json` to be

docs/tooling/package-metadata.md

@@ -48,11 +48,11 @@ The main entry point of the package, as defined by [NPM](https://docs.npmjs.com/
 
 The exports of the package, as defined by [Node.js](https://nodejs.org/api/packages.html#exports). This field is used to define the entry points of the package. As with other entry point fields, the exports should point to entry points for local development. They will the be rewritten when packaging the package for distribution. You can read more about this in the [sub-path exports](./cli/02-build-system.md#subpath-exports) section.
 
-### `typeVersions`
+### `typesVersions`
 
 This field is used to specify versioned type entry points for the package, as defined by [TypeScript](https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions), and is used as the equivalent of the `exports` field. TypeScript does support type declarations in the `exports` field, but that requires that the `moduleResolution` option in `tsconfig.json` is set to `node16` or `bundler`, which the Backstage ecosystem currently does not support.
 
-This field can be generated by the `backstage-cli repo fix` command. First fill out the `exports` field to point to source fields, which will then be used to generate `typeVersions`.
+This field can be generated by the `backstage-cli repo fix` command. First fill out the `exports` field to point to source fields, which will then be used to generate `typesVersions`.
 
 ### `sideEffects`
 
@@ -168,6 +168,45 @@ The presence of this field is checked by the `backstage-cli package prepack` com
 }
 ```
 
+### `backstage.peerModules`
+
+For plugin packages, this optional field declares modules that should be installed alongside this plugin for cross-plugin integrations. If the peer module's target plugin is present in the Backstage installation, you should typically have the peer module installed as well.
+
+For example, if you use `@backstage/plugin-scaffolder-backend`, you should also install `@backstage/plugin-catalog-backend-module-scaffolder-entity-model` to enable catalog support for scaffolder entity templates. The scaffolder plugin declares this relationship through `peerModules`.
+
+The field uses full package names to allow precise targeting of specific modules. This field can only be used on plugin packages (`backend-plugin` or `frontend-plugin` roles).
+
+```js title="Example usage of the backstage.peerModules field"
+{
+  "name": "@backstage/plugin-scaffolder-backend",
+  "backstage": {
+    "role": "backend-plugin",
+    "pluginId": "scaffolder",
+    "peerModules": [
+      "@backstage/plugin-catalog-backend-module-scaffolder-entity-model"
+    ]
+  }
+  ...
+}
+```
+
+A plugin can declare multiple peer modules:
+
+```js title="Example of multiple peer modules"
+{
+  "name": "@example/plugin-catalog-backend",
+  "backstage": {
+    "role": "backend-plugin",
+    "pluginId": "catalog",
+    "peerModules": [
+      "@example/plugin-search-backend-module-catalog",
+      "@example/plugin-explore-backend-module-catalog"
+    ]
+  }
+  ...
+}
+```
+
 ### `backstage.moved`
 
 This field indicates that a package has been renamed and moved to a new location. This field is recognized by the Backstage CLI, where the version bump command will automatically switch to using the new package instead. The value of this field should be the new package name.