Merge pull request #32594 from backstage/rugvip/docs-fixes

docs: apply minor fixes from feedback

docs/auth/index.md

@@ -211,6 +211,8 @@ to get the existing session, which is exactly what the `ProxiedSignInPage` does.
 thing you need to do to configure the `ProxiedSignInPage` is to pass the ID of the provider like this:
 
 ```tsx title="packages/app/src/App.tsx"
+import { ProxiedSignInPage } from '@backstage/core-components';
+
 const app = createApp({
   components: {
     SignInPage: props => <ProxiedSignInPage {...props} provider="awsalb" />,

docs/auth/oidc.md

@@ -136,7 +136,15 @@ auth:
             - resolver: emailMatchingUserEntityProfileEmail
 ```
 
-If none of the built-in resolvers are suitable, you can alternatively write a custom resolver. See an example below:
+If none of the built-in resolvers are suitable, you can alternatively write a custom resolver.
+
+First, install the OIDC provider module:
+
+```bash
+yarn --cwd packages/backend add @backstage/plugin-auth-backend-module-oidc-provider
+```
+
+Then create a custom resolver as shown below:
 
 ```ts title="in packages/backend/src/index.ts"
 /* highlight-add-start */
@@ -146,6 +154,10 @@ import {
   createOAuthProviderFactory,
 } from '@backstage/plugin-auth-node';
 import { oidcAuthenticator } from '@backstage/plugin-auth-backend-module-oidc-provider';
+import {
+  stringifyEntityRef,
+  DEFAULT_NAMESPACE,
+} from '@backstage/catalog-model';
 
 const myAuthProviderModule = createBackendModule({
   // This ID must be exactly "auth" because that's the plugin it targets
@@ -168,7 +180,7 @@ const myAuthProviderModule = createBackendModule({
             async signInResolver(info, ctx) {
               const userRef = stringifyEntityRef({
                 kind: 'User',
-                name: info.result.userinfo.sub,
+                name: info.result.fullProfile.userinfo.sub,
                 namespace: DEFAULT_NAMESPACE,
               });
               return ctx.issueToken({

docs/backend-system/core-services/root-http-router.md

@@ -164,7 +164,7 @@ Note that requests towards `/api/*` will never be handled by the `routes` handle
 
 The root HTTP Router service also allows for configuration of the underlying Node.js HTTP server object. This is useful for modifying settings on the HTTP server itself, such as server [`timeout`](https://nodejs.org/api/http.html#servertimeout), [`keepAliveTimeout`](https://nodejs.org/api/http.html#serverkeepalivetimeout), and [`headersTimeout`](https://nodejs.org/api/http.html#serverheaderstimeout).
 
-A `applyDefaults` helper is also made available to use the default app/router configuration while still enabling custom server configuration
+An `applyDefaults` helper is also made available to use the default app/router configuration while still enabling custom server configuration
 
 ```ts
 import { rootHttpRouterServiceFactory } from '@backstage/backend-defaults/rootHttpRouter';

docs/features/software-templates/writing-custom-actions.md

@@ -91,8 +91,8 @@ The `createTemplateAction` takes an object which specifies the following:
   may ship with the `scaffolder-backend` plugin.
 - `description` - An optional field to describe the purpose of the action. This will populate in the `/create/actions`
   endpoint.
-- `schema.input` - A `zod` or JSON schema object for input values to your function
-- `schema.output` - A `zod` or JSON schema object for values which are output from the
+- `schema.input` - A `zod` schema object for input values to your function
+- `schema.output` - A `zod` schema object for values which are output from the
   function using `ctx.output`
 - `handler` - the actual code which is run as part of the action, with a context
 
@@ -195,7 +195,7 @@ argument. It looks like the following:
   executed successfully on the previous run.
 - `ctx.logger` - a [LoggerService](../../backend-system/core-services/logger.md) instance for additional logging inside your action
 - `ctx.workspacePath` - a string of the working directory of the template run
-- `ctx.input` - an object which should match the `zod` or JSON schema provided in the
+- `ctx.input` - an object which should match the `zod` schema provided in the
   `schema.input` part of the action definition
 - `ctx.output` - a function which you can call to set outputs that match the
   `zod` schema in `schema.output` for ex. `ctx.output('downloadUrl', myDownloadUrl)`

docs/getting-started/index.md

@@ -81,7 +81,7 @@ This guide also assumes a basic understanding of working on a Linux based operat
   - Using `nvm` (recommended)
     - [Installing nvm](https://github.com/nvm-sh/nvm#install--update-script)
     - [Install and change Node version with nvm](https://nodejs.org/en/download/package-manager/#nvm)
-    - Node 24 is a good starting point, this can be installed using `nvm install lts/krypton`
+    - Node 22 or 24 are recommended, these can be installed using `nvm install 22` or `nvm install 24`
   - [Binary Download](https://nodejs.org/en/download/)
   - [Package manager](https://nodejs.org/en/download/package-manager/)
   - [Using NodeSource packages](https://github.com/nodesource/distributions/blob/master/README.md)

docs/notifications/index.md

@@ -147,9 +147,6 @@ add the `UserNotificationSettingsCard` to your frontend.
 
 ```tsx title="packages/app/src/App.tsx"
 <Route path="/settings" element={<UserSettingsPage />}>
-  <SettingsLayout.Route path="/advanced" title="Advanced">
-    <AdvancedSettings />
-  </SettingsLayout.Route>
   <SettingsLayout.Route path="/notifications" title="Notifications">
     <UserNotificationSettingsCard
       originNames={{ 'plugin:scaffolder': 'Scaffolder' }}

docs/overview/threat-model.md

@@ -19,7 +19,7 @@ An **operator** is a user responsible for configuring and maintaining an instanc
 
 A **builder** is an internal or external code contributor and end up having a similar level of access as operators. When installing Backstage plugins you should vet them just like any other package from an external source. While it’s possible to limit the impact of for example a supply chain attack by splitting the deployment into separate services with different plugins, the Backstage project itself does not aim to prevent these kinds of attacks or in any other way sandbox or limit the access of plugins.
 
-An **external user** is a user that does not belong to the other two groups, for example a malicious actor outside of the organization. The security model of Backstage currently assumes that this group does not have any direct access to Backstage, and it is the responsibility of each adopter of Backstage to make sure this is the case.
+An **external user** is a user that does not belong to the other three groups, for example a malicious actor outside of the organization. The security model of Backstage currently assumes that this group does not have any direct access to Backstage, and it is the responsibility of each adopter of Backstage to make sure this is the case.
 
 ## Operator Responsibilities
 

docs/plugins/proxying.md

@@ -141,6 +141,9 @@ registered in this manner.
 Example:
 
 ```ts
+import { createBackendModule } from '@backstage/backend-plugin-api';
+import { proxyEndpointsExtensionPoint } from '@backstage/plugin-proxy-node';
+
 backend.add(
   createBackendModule({
     pluginId: 'proxy',

docs/tooling/cli/03-commands.md

@@ -286,7 +286,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`