docs: rename "lint" to "styleguide" in Redocly config (#791)

.github/workflows/tests.yaml

@@ -3,8 +3,6 @@ name: Build and Test
 on:
   pull_request:
     types: [opened, synchronize, reopened]
-    paths-ignore:
-      - 'docs/**'
   push:
     branches:
       - master

docs/configuration/index.mdx

@@ -56,7 +56,7 @@ organization: testing_redocly
 apis:
   core@v2:
     root: ./openapi/openapi.yaml
-    lint:
+    styleguide:
       rules:
         no-ambiguous-paths: error
   external@v1:
@@ -66,7 +66,7 @@ apis:
     features.openapi:
       hideLogo: true
 
-lint:
+styleguide:
   extends:
     - recommended
 
@@ -105,7 +105,7 @@ apis:
     root: ./openapi/openapi.yaml
     labels:
       - production
-    lint: {}
+    styleguide: {}
     features.openapi: {}
 ```
 
@@ -160,7 +160,7 @@ You may also import plugins and extends their configurations.
 #### Example
 
 ```yaml
-lint:
+styleguide:
   extends:
     - recommended
   rules:

docs/configuration/schema.yaml

@@ -42,7 +42,7 @@ properties:
             If you try to assign labels that don't already exist for your organization, Redocly apps will display a warning in the output and will only assign the existing labels (if any).
           items:
             type: string
-        lint:
+        styleguide:
           type: object
           description: >-
             Configures linting options for the specified API.
@@ -60,7 +60,7 @@ properties:
             Defines mock server behavior for an API definition.
             Supports the same format and options as the global `features.mockServer` object.
             API-level configuration will always override global configuration.
-  lint:
+  styleguide:
     type: object
     description: Lets you set rules and decorators that control how the `lint` and `bundle` commands behave.
     properties:

docs/decorators.md

@@ -36,11 +36,11 @@ The following example shows how to configure a decorator in the [Redocly configu
 apis:
   main:
     root: ./openapi/openapi.yaml
-    lint:
+    styleguide:
       decorators:
         decorator-name:
           decorator-option: example-value
-lint:
+styleguide:
   decorators:
     decorator-name:
       decorator-option: example-value

docs/decorators/filter-in.md

@@ -18,7 +18,7 @@ Giant monolithic API docs can overwhelm anyone. By filtering what is most releva
 Example of configuration:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     filter-in:
       property: x-audience

docs/decorators/filter-out.md

@@ -18,7 +18,7 @@ Giant monolithic API docs can overwhelm anyone. By filtering what is most releva
 Example of configuration:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     filter-out:
       property: x-audience

docs/decorators/info-description-override.md

@@ -18,7 +18,7 @@ This decorator provides a way to "overlay" a new description over the source so
 Example of a configuration:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     info-description-override:
       filePath: ./my-custom-description.md

docs/decorators/operation-description-override.md

@@ -18,7 +18,7 @@ This decorator provides a way to "overlay" a new description over the source so
 Example of a configuration:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     operation-description-override:
       operationIds:

docs/decorators/remove-x-internal.md

@@ -17,7 +17,7 @@ This is a mechanism that can be used to maintain them together but generate two
 Example of a configuration that uses `x-internal` as the flag property:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     remove-x-internal: on
 ```
@@ -25,7 +25,7 @@ lint:
 Example of another configuration that changes the flag property:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     remove-x-internal:
       internalFlagProperty: 'x-private'

docs/decorators/tag-description-override.md

@@ -18,7 +18,7 @@ This decorator provides a way to "overlay" a new description over the source so
 Example of a configuration:
 
 ```yaml
-lint:
+styleguide:
   decorators:
     tag-description-override:
       tagNames:

docs/guides/change-token-url.md

@@ -16,14 +16,13 @@ Estimated time: 20 minutes
 
 1. Add this code to your repo with the API (the Redocly configuration file is an example).
     ```yaml redocly.yaml
-    plugins:
-      lint:
-    extends:
-      - recommended
-    plugins:
-      - './plugins/acme-plugin.js'
-    decorators:
-      acme/change-token-urls: error
+    styleguide:
+      extends:
+        - recommended
+      plugins:
+        - './plugins/acme-plugin.js'
+      decorators:
+        acme/change-token-urls: error
     ```
 
     ```js acme-plugin.js

docs/guides/hide-apis.md

@@ -97,7 +97,7 @@ apis:
     root: ./sample.yaml
   external@latest:
     root: ./sample.yaml
-    lint:
+    styleguide:
       decorators:
         remove-x-internal: on
 ```

docs/guides/lint.md

@@ -14,10 +14,10 @@ The Redocly configuration file supports global lint settings (configured in the
 apis:
   main@v1:
     root: ./openapi/openapi.yaml
-    lint:
+    styleguide:
       rules: []
       (...)
-lint:
+styleguide:
   rules: []
   (...)
 ```
@@ -29,7 +29,7 @@ If per-API and global settings modify the same properties, per-API settings will
 The `lint` configuration consists of several lists and objects. The following code block shows an example `lint` configuration. Its contents are described further in the text.
 
 ```yaml
-lint:
+styleguide:
   plugins:
     - './local-plugin.js'
   extends:
@@ -69,13 +69,13 @@ Community plugins are not supported.
 ### Examples
 
 ```yaml Import a single plugin
-lint:
+styleguide:
   plugins:
     - './local-plugin.js'
 ```
 
 ```yaml Import multiple plugins
-lint:
+styleguide:
   plugins:
     - ['./local-plugin.js', './another-local-plugin.js']
 ```
@@ -108,7 +108,7 @@ It supports the following types of values:
 When providing values as URLs, they must be publicly accessible.
 
 ```yaml
-lint:
+styleguide:
   extends:
     - built-in-configuration-name
     - local-plugin-name/configuration-name
@@ -140,13 +140,13 @@ Any additional configuration must be in a YAML file, and must conform to the Red
 **Example: using an additional configuration file**
 
 ```yaml Main redocly.yaml
-lint:
+styleguide:
   extends:
     - ./other-configuration.yaml
 ```
 
 ```yaml Linked other-configuration.yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: error
     no-invalid-schema-examples:
@@ -161,7 +161,7 @@ If you add another Redocly configuration file to the `extends` list, the setting
 **Example: using an additional configuration file**
 
 ```yaml Main redocly.yaml
-lint:
+styleguide:
   extends:
     - ./testing/redocly.yaml
 ```
@@ -170,7 +170,7 @@ lint:
 apis:
   testing-api:
     (...)
-lint:
+styleguide:
   rules:
     tags-alphabetical: error
     no-invalid-schema-examples:
@@ -192,13 +192,13 @@ Custom plugins can't contain the `extends` list because recursive extension is n
 The following examples illustrate configuration nesting with multiple configuration files.
 
 ```yaml Main redocly.yaml
-lint:
+styleguide:
   extends:
     - custom.yaml
 ```
 
 ```yaml custom.yaml
-lint:
+styleguide:
   extends:
     - nested.yaml
   rules:
@@ -207,7 +207,7 @@ lint:
 ```
 
 ```yaml nested.yaml
-lint:
+styleguide:
   rules:
     path-parameters-defined: error
     tag-description: warn
@@ -228,7 +228,7 @@ Due to the conflict, priority goes to the inline `rules` over the `extends` list
 
 
 ```yaml redocly.yaml
-lint:
+styleguide:
   extends:
     - custom.yaml
   rules:
@@ -237,7 +237,7 @@ lint:
 ```
 
 ```yaml custom.yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: warn
     path-parameters-defined: warn
@@ -252,21 +252,21 @@ In the following example, Redocly CLI will use the setting for the conflicting `
 This means you can control the priority of configurations by reordering them in the `extends` list, and override all lint configurations (custom and built-in) by specifying individual rule settings in the `rules` object.
 
 ```yaml redocly.yaml
-lint:
+styleguide:
   extends:
     - custom.yaml
     - testing.yaml
 ```
 
 ```yaml custom.yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: warn
     paths-kebab-case: warn
 ```
 
 ```yaml testing.yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: error
     path-parameters-defined: warn
@@ -301,13 +301,13 @@ For `bundle` command: rules run *between* preprocessors and decorators.
 ### Examples
 
 ```yaml Short syntax
-lint:
+styleguide:
   rules:
     no-sibling-refs: error
 ```
 
 ```yaml Verbose syntax
-lint:
+styleguide:
   rules:
     no-sibling-refs:
       severity: error
@@ -316,7 +316,7 @@ lint:
 ```yaml Rules with additional configuration
 # Use verbose configuration syntax to define additional configuration
 # The boolean-parameter-prefixes example overrides the default "prefixes".
-lint:
+styleguide:
   rules:
     boolean-parameter-prefixes:
       severity: error
@@ -348,7 +348,7 @@ For the `bundle` command, linting happens only when the `--lint` flag is used.
 With the short configuration syntax, you can't configure [additional options](#additional-rule-options) for any given rule (if it supports them).
 
 ```yaml Short syntax
-lint:
+styleguide:
   extends:
     - recommended
   rules:
@@ -357,7 +357,7 @@ lint:
 ```
 
 ```yaml Verbose syntax
-lint:
+styleguide:
   extends:
     - recommended
   rules:
@@ -378,7 +378,7 @@ See the [rules documentation](../rules.md) for more information.
 The example below shows additional rule options for the `boolean-parameter-prefixes` rule:
 
 ```yaml
-lint:
+styleguide:
   extends:
     - recommended
   rules:
@@ -403,7 +403,7 @@ Be sure to document those options for your users.
 Redocly CLI supports OpenAPI versions 2.0, 3.0, and 3.1. Most of the time, you will use one of them. However, you may need to configure different rules based on the version. You can do that by using special objects in your configuration.
 
 ```yaml
-lint:
+styleguide:
   extends:
     - recommended
   rules:
@@ -437,7 +437,7 @@ Starting from version `beta-30` onward, Redocly CLI automatically resolves all `
 To disable resolving `$refs` in examples, use the `doNotResolveExamples` option in the `lint` object of the Redocly configuration file. This does not affect `$ref` resolution in other parts of the API definition:
 
 ```yaml
-lint:
+styleguide:
   doNotResolveExamples: true
   extends:
     - recommended

docs/guides/replace-server-url.md

@@ -104,7 +104,7 @@ To use the decorator, you will need to register your plugin in your Redocly conf
 apis:
   main:
     root: openapi/openapi.yaml
-lint:
+styleguide:
   extends:
     - recommended
   plugins:

docs/guides/response-contains-property.md

@@ -80,7 +80,7 @@ function ResponseContainsProperty (options) {
 We would configure this in our Redocly configuration file like this:
 
 ```yaml
-lint:
+styleguide:
   rules:
     demo/response-contains-property:
       severity: warn
@@ -205,7 +205,7 @@ apis:
     root: openapi/internal.yaml
   main:
     root: openapi/external.yaml
-lint:
+styleguide:
   extends:
     - recommended
   plugins:

docs/resources/custom-rules.md

@@ -35,7 +35,7 @@ Plugins need to be explicitly defined in the configuration file (except for the
 Plugins then are consumed by designating their configuration in the `extends` section of the configuration.
 
 ```yaml
-lint:
+styleguide:
   plugins:
     - 'my-plugin.js'
   extends:

docs/rules.md

@@ -100,10 +100,10 @@ You can format each entry in the `lint` and `rules` object in one of the followi
 apis:
   main:
     root: ./openapi/openapi.yaml
-    lint:
+    styleguide:
       rules:
         specific-api-rule: warn
-lint:
+styleguide:
   rules:
     example-rule-name: error
 ```
@@ -114,11 +114,11 @@ lint:
 apis:
   main:
     root: ./openapi/openapi.yaml
-    lint:
+    styleguide:
       rules:
         specific-api-rule:
           severity: warn
-lint:
+styleguide:
   rules:
     example-rule-name:
       severity: error
@@ -145,7 +145,7 @@ There are two built-in configurations:
 The recommended configuration can be enabled by adding
 
 ```yaml
-lint:
+styleguide:
   extends:
     - recommended
 ```

docs/rules/assertions.md

@@ -9,7 +9,7 @@ Configure assertions to enforce your API design standards without coding custom
 Define assertions in the `rules` map of the `lint` object in the Redocly configuration file.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/assertion-name:
       ...
@@ -76,7 +76,7 @@ In addition, the `Operation` summary property must:
 The following example shows how to configure those assertions:
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/tag-description:
       subject: Tag
@@ -118,7 +118,7 @@ lint:
 The following example asserts that every path item has a GET operation defined.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/path-item-get-operation-defined:
       subject: PathItem
@@ -131,7 +131,7 @@ A different way to declare the same assertion is to require that the `PathItem`
 Notice we don't need to include `property` in this approach.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/path-item-operation-required:
       subject: PathItem
@@ -143,7 +143,7 @@ lint:
 The following example asserts that Tags have both name and description defined.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/tag-name-and-desc-defined:
       subject: Tag
@@ -157,7 +157,7 @@ lint:
 Another way to compose that rule is to require the subject keys:
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/tag-name-and-desc-required:
       subject: Tag
@@ -191,7 +191,7 @@ assert/no-pdf-in-ok-response:
 The following example asserts that only `application/json` can be used as a key of the MediaTypeMap.
 
 ```yaml keys
-lint:
+styleguide:
   rules:
     assert/media-type-map-application-json:
       subject: MediaTypeMap
@@ -204,7 +204,7 @@ lint:
 The following example asserts that the operation summary must match one of the listed enums.
 
 ```yaml values
-lint:
+styleguide:
   rules:
     assert/operation-summary-match:
       subject: Operation
@@ -224,7 +224,7 @@ lint:
 The following example asserts that the operation summary contains "test".
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/operation-summary-contains-test:
       subject: Operation
@@ -239,7 +239,7 @@ lint:
 The following example asserts the casing style is `PascalCase` for NamedExamples map keys.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/named-examples-pascal-case:
       subject: NamedExamples
@@ -264,7 +264,7 @@ The following example asserts the operation `description` and `externalDocs` mus
 This assertion evaluates only property keys for the node, but not property values.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/operation-no-both-description-and-external-docs:
       subject: Operation
@@ -281,7 +281,7 @@ The following example asserts that a response body schema must have both `amount
 This assertion evaluates only property keys for the node, but not property values.
 
 ```yaml Schema example
-lint:
+styleguide:
   rules:
     assert/schema-properties-both-created-at-and-updated-at:
       subject: SchemaProperties
@@ -295,7 +295,7 @@ lint:
 The following example asserts that when `PUT` requests have either `200` or `201` defined, both `200` and `201` responses must be defined.
 
 ```yaml Response example
-lint:
+styleguide:
   rules:
     assert/put-200-and-201:
       subject: ResponsesMap
@@ -316,7 +316,7 @@ The following example asserts that `PUT` requests have both `200` and `201` resp
 The difference between `mutuallyRequired` is that neither `200` and `201` need to be defined for it to meet `mutuallyRequired` evaluations.
 
 ```yaml Response example
-lint:
+styleguide:
   rules:
     assert/put-200-and-201:
       subject: ResponsesMap
@@ -337,7 +337,7 @@ The following example asserts that an operation must have either `description` o
 This assertion evaluates only property keys for the node, but not property values.
 
 ```yaml Response example
-lint:
+styleguide:
   rules:
     assert/operation-no-both-description-and-external-docs:
       subject: Operation
@@ -353,7 +353,7 @@ lint:
 The following example asserts that `x-code-samples` and `x-internal` are not defined.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/no-x-code-samples-and-x-internal:
       subject: Operation
@@ -369,7 +369,7 @@ lint:
 The following example asserts that `x-codeSamples` is defined.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/x-code-samples-defined:
       subject: Operation
@@ -384,7 +384,7 @@ lint:
 The following example asserts that `x-code-samples` is undefined.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/x-code-samples-undefined:
       subject: Operation
@@ -401,7 +401,7 @@ lint:
 The following example asserts that the operation summary is not empty.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/operation-summary-non-empty:
       subject: Operation
@@ -416,7 +416,7 @@ lint:
 The following example asserts that the minimum length of each operation summary is 20 characters.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/operation-summary-min-length:
       subject: Operation
@@ -431,7 +431,7 @@ lint:
 The following example asserts that the maximum length of each operation summary is 20 characters.
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/operation-summary-max-length:
       subject: Operation
@@ -446,7 +446,7 @@ lint:
 The following example asserts that schema in MediaType contains a Reference object ($ref).
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/mediatype-schema-has-ref:
       subject: MediaType
@@ -458,7 +458,7 @@ lint:
 Also, you can specify a Regular Expression to check if the reference object conforms to it:
 
 ```yaml
-lint:
+styleguide:
   rules:
     assert/mediatype-schema-ref-pattern:
       subject: MediaType

docs/rules/boolean-parameter-prefixes.md

@@ -50,14 +50,14 @@ The nuance of being able to identify the boolean parameters helps developers pro
 
 An example configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     boolean-parameter-prefixes: error
 ```
 
 The following example configures prefixes:
 ```yaml
-lint:
+styleguide:
   rules:
     boolean-parameter-prefixes:
       severity: error

docs/rules/info-contact.md

@@ -31,7 +31,7 @@ If they need help to purchase, integrate, or troubleshoot, your contact info sho
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     info-contact: warn
 ```
@@ -40,7 +40,7 @@ lint:
 
 Given this configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     info-contact: error
 ```

docs/rules/info-license-url.md

@@ -36,7 +36,7 @@ By being upfront with the API license, you can reduce friction towards usage.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     info-license-url: error
 ```
@@ -45,7 +45,7 @@ lint:
 
 Given the following configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     info-license-url: error
 ```

docs/rules/info-license.md

@@ -36,7 +36,7 @@ By being upfront with the API license, you can reduce friction towards usage.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     info-license: error
 ```
@@ -45,7 +45,7 @@ lint:
 
 Given the following configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     info-license: error
 ```

docs/rules/no-ambiguous-paths.md

@@ -50,7 +50,7 @@ Such paths are considered ambiguous and should be avoided, because API users and
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-ambiguous-paths: error
 ```
@@ -60,7 +60,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-ambiguous-paths: error
 ```

docs/rules/no-empty-enum-servers.md

@@ -34,7 +34,7 @@ In the case of environment-driven variables, you may want to predefine all of th
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-empty-enum-servers: error
 ```
@@ -44,7 +44,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-empty-enum-servers: error
 ```

docs/rules/no-empty-servers.md

@@ -43,7 +43,7 @@ servers:
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-empty-servers: error
 ```
@@ -53,7 +53,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-empty-servers: error
 ```

docs/rules/no-enum-type-mismatch.md

@@ -42,7 +42,7 @@ Lack of compliance is most likely the result of a typo.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-enum-type-mismatch: error
 ```
@@ -52,7 +52,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-enum-type-mismatch: error
 ```

docs/rules/no-example-value-and-externalValue.md

@@ -42,7 +42,7 @@ The intended use of the `value` field is to provide in-line example values, whil
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-example-value-and-externalValue: error
 ```
@@ -51,7 +51,7 @@ lint:
 
 Given this configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     no-example-value-and-externalValue: error
 ```

docs/rules/no-http-verbs-in-paths.md

@@ -48,7 +48,7 @@ With the `splitIntoWords` enabled it will be identified as a resource and not tr
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-http-verbs-in-paths: error
 ```
@@ -56,7 +56,7 @@ lint:
 An example configuration with `splitIntoWords` enabled:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-http-verbs-in-paths:
       severity: error
@@ -68,7 +68,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-http-verbs-in-paths: error
 ```
@@ -94,7 +94,7 @@ paths:
 Given the following configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-http-verbs-in-paths:
       severity: error

docs/rules/no-identical-paths.md

@@ -37,7 +37,7 @@ Minimize it in APIs to make them as easy as possible to use.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-identical-paths: error
 ```
@@ -47,7 +47,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-identical-paths: error
 ```

docs/rules/no-invalid-media-type-examples.md

@@ -46,7 +46,7 @@ It's much nicer to get this alert from Redocly before you ship than from your bi
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-media-type-examples:
       severity: error
@@ -58,7 +58,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-media-type-examples:
       severity: error

docs/rules/no-invalid-parameter-examples.md

@@ -42,7 +42,7 @@ Solve it before you ship it.
 |disallowAdditionalProperties|boolean|Determines if additional properties are allowed in examples. Default `true`. |
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-parameter-examples:
       severity: error
@@ -54,7 +54,7 @@ lint:
 Given the following configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-parameter-examples:
       severity: error

docs/rules/no-invalid-schema-examples.md

@@ -45,7 +45,7 @@ Solve it before you ship it.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-schema-examples:
       severity: error
@@ -57,7 +57,7 @@ lint:
 Given the following configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-invalid-schema-examples:
       severity: error

docs/rules/no-path-trailing-slash.md

@@ -26,7 +26,7 @@ When it comes to developer experience, consistency rules.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-path-trailing-slash: error
 ```
@@ -35,7 +35,7 @@ lint:
 
 Given this configuration:
 ```yaml
-lint:
+styleguide:
   rules:
     no-path-trailing-slash: error
 ```

docs/rules/no-server-example-com.md

@@ -35,7 +35,7 @@ If you can't reveal a production server, consider a [Redocly mock server](/docs/
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-server-example-com: error
 ```
@@ -45,7 +45,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-server-example-com: error
 ```

docs/rules/no-server-trailing-slash.md

@@ -37,7 +37,7 @@ Hands-down a good rule for every API designer.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-server-trailing-slash: error
 ```
@@ -47,7 +47,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-server-trailing-slash: error
 ```

docs/rules/no-undefined-server-variable.md

@@ -32,7 +32,7 @@ It is important to fix these errors to help clients consume APIs.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-undefined-server-variable: error
 ```
@@ -42,7 +42,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-undefined-server-variable: error
 ```

docs/rules/no-unresolved-refs.md

@@ -25,7 +25,7 @@ This rule prevents that from happening.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-unresolved-refs: error
 ```
@@ -35,7 +35,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-unresolved-refs: error
 ```

docs/rules/no-unused-components.md

@@ -35,7 +35,7 @@ If that describes your use-case, turn this rule off.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-unused-components: error
 ```
@@ -45,7 +45,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     no-unused-components: error
 ```

docs/rules/operation-2xx-response.md

@@ -27,7 +27,7 @@ You can greatly improve the developer and user experience of your APIs by making
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-2xx-response: error
 ```
@@ -37,7 +37,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-2xx-response: error
 ```

docs/rules/operation-4xx-response.md

@@ -25,7 +25,7 @@ While this thinking has mostly changed (for the better in our opinion), it does
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-4xx-response: error
 ```
@@ -35,7 +35,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-4xx-response: error
 ```

docs/rules/operation-description.md

@@ -30,7 +30,7 @@ Do this, and your API consumers will thank you.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-description: error
 ```
@@ -40,7 +40,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-description: error
 ```

docs/rules/operation-operationId-unique.md

@@ -25,7 +25,7 @@ This rule is unopinionated.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId-unique: error
 ```
@@ -35,7 +35,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId-unique: error
 ```

docs/rules/operation-operationId-url-safe.md

@@ -24,7 +24,7 @@ This rule is unopinionated.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId-url-safe: error
 ```
@@ -34,7 +34,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId-url-safe: error
 ```

docs/rules/operation-operationId.md

@@ -24,7 +24,7 @@ If it annoys the lazy or minimalists, offer them an alternative: two weeks at Re
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId: error
 ```
@@ -34,7 +34,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-operationId: error
 ```

docs/rules/operation-parameters-unique.md

@@ -25,7 +25,7 @@ Solve it before you ship it.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-parameters-unique: error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-parameters-unique: error
 ```

docs/rules/operation-security-defined.md

@@ -41,7 +41,7 @@ security: []
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-security-defined: error
 ```
@@ -51,7 +51,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-security-defined: error
 ```

docs/rules/operation-singular-tag.md

@@ -28,7 +28,7 @@ Simple wins.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-singular-tag: error
 ```
@@ -38,7 +38,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-singular-tag: error
 ```

docs/rules/operation-summary.md

@@ -24,7 +24,7 @@ Redocly uses the summary as the header for the operation, as well as the sidebar
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-summary: error
 ```
@@ -34,7 +34,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-summary: error
 ```

docs/rules/operation-tag-defined.md

@@ -28,7 +28,7 @@ This rule helps prevent typos and tag explosion.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-tag-defined: error
 ```
@@ -39,7 +39,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     operation-tag-defined: error
 ```

docs/rules/parameter-description.md

@@ -25,7 +25,7 @@ Document it!
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     parameter-description: error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     parameter-description: error
 ```

docs/rules/path-declaration-must-exist.md

@@ -25,7 +25,7 @@ This rule is not opinionated.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-declaration-must-exist: error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-declaration-must-exist: error
 ```

docs/rules/path-excludes-patterns.md

@@ -32,7 +32,7 @@ Other ideas are around casing (other than kebab-case, which is a common approach
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-excludes-patterns:
       severity: error
@@ -45,7 +45,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-excludes-patterns:
       severity: error

docs/rules/path-not-include-query.md

@@ -25,7 +25,7 @@ Its root cause is inexperience with OpenAPI (no holy war here).
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     : error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     : error
 ```

docs/rules/path-parameters-defined.md

@@ -25,7 +25,7 @@ This rule verifies the path parameters are defined.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-parameters-defined: error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-parameters-defined: error
 ```

docs/rules/path-segment-plural.md

@@ -34,7 +34,7 @@ Nothing wrong with that.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-segment-plural: error
 ```
@@ -42,7 +42,7 @@ lint:
 Another example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-segment-plural:
       severity: error
@@ -58,7 +58,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     path-segment-plural: error
 ```

docs/rules/paths-kebab-case.md

@@ -34,7 +34,7 @@ We don't want to say we told ya so!
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     paths-kebab-case: error
 ```
@@ -45,7 +45,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     paths-kebab-case: error
 ```

docs/rules/request-mime-type.md

@@ -31,7 +31,7 @@ It doesn't matter to me... keep it consistent across your entire API if possible
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     request-mime-type:
       severity: error
@@ -44,7 +44,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     request-mime-type:
       severity: error

docs/rules/response-contains-header.md

@@ -23,7 +23,7 @@ In some cases, it is important to design an API so that it consistently returns
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-contains-header:
       severity: error
@@ -41,7 +41,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-contains-header:
       severity: error

docs/rules/response-contains-property.md

@@ -24,7 +24,7 @@ In some cases, it is important to design an API so that it consistently returns
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-contains-property:
       severity: error
@@ -42,7 +42,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-contains-property:
       severity: error

docs/rules/response-mime-type.md

@@ -32,7 +32,7 @@ Keep it consistent across your entire API if possible.
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-mime-type:
       severity: error
@@ -45,7 +45,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     response-mime-type:
       severity: error

docs/rules/scalar-property-missing-example.md

@@ -21,7 +21,7 @@ To configure the rule, add it to the `lint.rules` section of your configuration
 Set the desired [severity](/docs/cli/rules.md#severity-settings) for the rule.
 
 ```yaml
-lint:
+styleguide:
   rules:
     scalar-property-missing-example:
       severity: error
@@ -37,7 +37,7 @@ lint:
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     scalar-property-missing-example: error
 ```
@@ -48,7 +48,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     scalar-property-missing-example: error
 ```

docs/rules/spec.md

@@ -26,7 +26,7 @@ It's important to conform to the specification so that tools work with your API
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     spec: error
 ```
@@ -36,7 +36,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     spec: error
 ```

docs/rules/tag-description.md

@@ -41,7 +41,7 @@ To configure the rule, add it to the `lint.rules` section of your configuration
 Set the desired [severity](/docs/cli/rules.md#severity-settings) for the rule.
 
 ```yaml
-lint:
+styleguide:
   rules:
     info-contact: error
 ```
@@ -56,7 +56,7 @@ lint:
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     : error
 ```
@@ -67,7 +67,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     : error
 ```

docs/rules/tags-alphabetical.md

@@ -37,7 +37,7 @@ This rule is intended to prevent bikeshedding and diffuse tension between teamma
 An example configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: error
 ```
@@ -47,7 +47,7 @@ lint:
 Given this configuration:
 
 ```yaml
-lint:
+styleguide:
   rules:
     tags-alphabetical: error
 ```