diff --git a/.changeset/brave-plants-drop.md b/.changeset/brave-plants-drop.md new file mode 100644 index 0000000000..fb4483c3e8 --- /dev/null +++ b/.changeset/brave-plants-drop.md @@ -0,0 +1,5 @@ +--- +'@backstage/eslint-plugin': patch +--- + +Minor doc updates diff --git a/.github/vale/config/vocabularies/Backstage/accept.txt b/.github/vale/config/vocabularies/Backstage/accept.txt index db3f3adf2c..77b0fb1d46 100644 --- a/.github/vale/config/vocabularies/Backstage/accept.txt +++ b/.github/vale/config/vocabularies/Backstage/accept.txt @@ -49,6 +49,7 @@ bursty callout CDNs Chai +Chainguard changeset changesets Changesets @@ -220,6 +221,7 @@ jq js json jsonnet +JSONSchema jsx JWTs Kaewkasi @@ -417,6 +419,7 @@ sanitization scaffolded scaffolder Scaffolder +scalprum SCM SCMs scrollable @@ -467,6 +470,8 @@ subheaders subkey subpage subpath +subpaths +subroute subroutes substring subtree @@ -491,6 +496,7 @@ templaters Templaters TFRecord theia +Themer threenager thumbsup todo diff --git a/docs/features/kubernetes/configuration.md b/docs/features/kubernetes/configuration.md index 830027f53b..6a3f3760bf 100644 --- a/docs/features/kubernetes/configuration.md +++ b/docs/features/kubernetes/configuration.md @@ -441,7 +441,7 @@ Base64-encoded certificate authority bundle in PEM format. The Kubernetes client will verify that the TLS certificate presented by the API server is signed by this CA. -This value could be obtained via inspecting the kubeconfig file (usually +This value could be obtained via inspecting the `kubeconfig` file (usually at `~/.kube/config`) under `clusters[*].cluster.certificate-authority-data`. For GKE, execute the following command to obtain the value @@ -619,7 +619,7 @@ The custom resource's group. #### `customResources.\*.apiVersion` -The custom resource's apiVersion. +The custom resource's `apiVersion`. #### `customResources.\*.plural` diff --git a/docs/features/software-catalog/api.md b/docs/features/software-catalog/api.md index 2a431d337b..96420cd37e 100644 --- a/docs/features/software-catalog/api.md +++ b/docs/features/software-catalog/api.md @@ -175,7 +175,7 @@ Some more real world usable examples: #### Ordering -By default the entities are returned ordered by their internal uid. You can +By default the entities are returned ordered by their internal `uid`. You can customize the `orderField` query parameters to affect that ordering. For example, to return entities by their name: diff --git a/docs/features/software-catalog/extending-the-model--old.md b/docs/features/software-catalog/extending-the-model--old.md index 00a6688352..c39561d11b 100644 --- a/docs/features/software-catalog/extending-the-model--old.md +++ b/docs/features/software-catalog/extending-the-model--old.md @@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box: We'll list different possibilities for extending this below. -## Adding a New apiVersion of an Existing Kind +## Adding a New `apiVersion` of an Existing Kind Example intents: > "I want to evolve this core kind, tweaking the semantics a bit so I will bump -> the apiVersion a step" +> the `apiVersion` a step" > "This core kind is a decent fit but we want to evolve it at will so we'll move -> it to our own company's apiVersion space and use that instead of +> it to our own company's `apiVersion` space and use that instead of > `backstage.io`." -The `backstage.io` apiVersion space is reserved for use by the Backstage +The `backstage.io` `apiVersion` space is reserved for use by the Backstage maintainers. Please do not change or add versions within that space. -If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required) +If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required) space of your own, you are effectively branching out from the underlying kind -and making your own. An entity kind is identified by the apiVersion + kind pair, +and making your own. An entity kind is identified by the `apiVersion` + `kind` pair, so even though the resulting entity may be similar to the core one, there will be no guarantees that plugins will be able to parse or understand its data. See below about adding a new kind. @@ -57,7 +57,7 @@ Example intents: > thing that is a poor fit for either of the builtins." > "This core kind is a decent fit but we want to evolve it at will so we'll move -> it to our own company's apiVersion space and use that instead of +> it to our own company's `apiVersion` space and use that instead of > `backstage.io`." A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching @@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition is to map things to these kinds, but sometimes you may want or need to extend beyond them. -Introducing a new apiVersion is basically the same as adding a new kind. Bear in +Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in mind that most plugins will be compiled against the builtin `@backstage/catalog-model` package and have expectations that kinds align with that. diff --git a/docs/features/software-catalog/extending-the-model.md b/docs/features/software-catalog/extending-the-model.md index 5d51a69e6b..7300f4f969 100644 --- a/docs/features/software-catalog/extending-the-model.md +++ b/docs/features/software-catalog/extending-the-model.md @@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box: We'll list different possibilities for extending this below. -## Adding a New apiVersion of an Existing Kind +## Adding a New `apiVersion` of an Existing Kind Example intents: > "I want to evolve this core kind, tweaking the semantics a bit so I will bump -> the apiVersion a step" +> the `apiVersion` a step" > "This core kind is a decent fit but we want to evolve it at will so we'll move -> it to our own company's apiVersion space and use that instead of +> it to our own company's `apiVersion` space and use that instead of > `backstage.io`." -The `backstage.io` apiVersion space is reserved for use by the Backstage +The `backstage.io` `apiVersion` space is reserved for use by the Backstage maintainers. Please do not change or add versions within that space. -If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required) +If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required) space of your own, you are effectively branching out from the underlying kind -and making your own. An entity kind is identified by the apiVersion + kind pair, +and making your own. An entity kind is identified by the `apiVersion` + `kind` pair, so even though the resulting entity may be similar to the core one, there will be no guarantees that plugins will be able to parse or understand its data. See below about adding a new kind. @@ -57,7 +57,7 @@ Example intents: > thing that is a poor fit for either of the builtins." > "This core kind is a decent fit but we want to evolve it at will so we'll move -> it to our own company's apiVersion space and use that instead of +> it to our own company's `apiVersion` space and use that instead of > `backstage.io`." A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching @@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition is to map things to these kinds, but sometimes you may want or need to extend beyond them. -Introducing a new apiVersion is basically the same as adding a new kind. Bear in +Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in mind that most plugins will be compiled against the builtin `@backstage/catalog-model` package and have expectations that kinds align with that. diff --git a/docs/tutorials/quickstart-app-plugin.md b/docs/tutorials/quickstart-app-plugin.md index e9b670c3ba..e9821f3f70 100644 --- a/docs/tutorials/quickstart-app-plugin.md +++ b/docs/tutorials/quickstart-app-plugin.md @@ -246,7 +246,7 @@ const auth = useApi(githubAuthApiRef); 2. The access token we need to make our GitHub request and the request itself is obtained in an asynchronous manner. -3. Add the useAsync block inside the ExampleFetchComponent +3. Add the `useAsync` block inside the ExampleFetchComponent ```tsx const { value, loading, error } = useAsync(async (): Promise => { diff --git a/packages/eslint-plugin/docs/rules/no-relative-monorepo-imports.md b/packages/eslint-plugin/docs/rules/no-relative-monorepo-imports.md index 6a41a73fb6..c53deef048 100644 --- a/packages/eslint-plugin/docs/rules/no-relative-monorepo-imports.md +++ b/packages/eslint-plugin/docs/rules/no-relative-monorepo-imports.md @@ -10,7 +10,7 @@ Add the rules as follows, it has no options: "@backstage/no-relative-monorepo-imports": ["error"] ``` -The following patterns are considered files used during development, and only need dependencies to be declared in devDependencies: +The following patterns are considered files used during development, and only need dependencies to be declared in `devDependencies`: ```python !src/** # Any files outside of src are considered dev files diff --git a/packages/eslint-plugin/docs/rules/no-undeclared-imports.md b/packages/eslint-plugin/docs/rules/no-undeclared-imports.md index 6102c772e6..2eee20e7c9 100644 --- a/packages/eslint-plugin/docs/rules/no-undeclared-imports.md +++ b/packages/eslint-plugin/docs/rules/no-undeclared-imports.md @@ -10,7 +10,7 @@ Add the rules as follows, it has no options: "@backstage/no-undeclared-imports": ["error"] ``` -The following patterns are considered files used during development, and only need dependencies to be declared in devDependencies: +The following patterns are considered files used during development, and only need dependencies to be declared in `devDependencies`: ```python !src/** # Any files outside of src are considered dev files