Merge branch 'main' into feat/respect-core-tree-shaking

Author: iosypov

.changeset/itchy-kiwis-notice.md

@@ -0,0 +1,6 @@
+---
+"@redocly/openapi-core": minor
+"@redocly/cli": minor
+---
+
+Implemented basic support for OpenRPC specification.

.github/CODEOWNERS

@@ -4,3 +4,5 @@
 README.md @Redocly/dark-side
 README.md @Redocly/technical-writers
 docs/ @Redocly/technical-writers
+packages/cli/src/utils/otel.ts @Redocly/hot-dogs
+packages/cli/src/utils/telemetry.ts @Redocly/hot-dogs

docs/@v2/commands/lint.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Redocly CLI can identify and report on problems found in OpenAPI, AsyncAPI, or Arazzo descriptions.
+Redocly CLI can identify and report on problems found in OpenAPI, AsyncAPI, Arazzo, or Open-RPC descriptions.
 This helps you avoid bugs and make API or Arazzo descriptions more consistent.
 
 The `lint` command reports on problems and executes preprocessors and rules.
@@ -50,7 +50,7 @@ The `lint` command behaves differently depending on how you pass the API(s) to i
 redocly lint openapi/openapi.yaml
 ```
 
-In this case, `lint` validates the API or Arazzo description(s) passed to the command.
+In this case, `lint` validates the API, Arazzo, or Open-RPC description(s) passed to the command.
 If you have no configuration file defined, the [recommended ruleset](../rules/recommended.md) is used.
 If you have `extends` or `rules` defined in `redocly.yaml`, those are used when linting.
 
@@ -432,3 +432,10 @@ The `lint` command also validates [The Arazzo](https://spec.openapis.org/arazzo/
 You can pass the Arazzo description file to the `lint` command as shown below:
 
 `redocly lint arazzo.yaml`
+
+### Lint Open-RPC description file
+
+The `lint` command also validates [Open-RPC](https://spec.open-rpc.org/) description files.
+You can pass the Open-RPC description file to the `lint` command as shown below:
+
+`redocly lint open-rpc.json`

docs/@v2/guides/index.md

@@ -61,6 +61,12 @@ API governance for async and streaming API applications.
 Check the validity of Arazzo descriptions for workflows.
 {% /card %}
 
+{% card title="Lint Open-RPC descriptions"
+    to="./lint-openrpc"
+  %}
+Check the validity of Open-RPC descriptions.
+{% /card %}
+
 {% card title="Change the OAuth2 token URL"
     to="./change-token-url"
   %}

docs/@v2/guides/lint-openrpc.md

@@ -0,0 +1,90 @@
+---
+seo:
+  title: Lint Open-RPC with Redocly CLI
+  description: Use the Redocly CLI to enforce basic validation, configure rules, or even build custom plugins for Open-RPC.
+---
+
+# Lint Open-RPC with Redocly CLI
+
+{% admonition type="info" name="Experimental Open-RPC support" %}
+This feature is at an early stage, please use with caution and send us lots of feedback!
+{% /admonition %}
+
+In addition to providing lint functionality for multiple OpenAPI formats, Redocly CLI also has support for Open-RPC.
+Redocly CLI supports the following linting approaches with Open-RPC documents:
+
+- Open-RPC document validation.
+- Supported versions:
+  - [Open-RPC 1.x](https://spec.open-rpc.org/)
+- Built-in rules for checking common standards requirements (see the [list of Open-RPC rules](#open-rpc-rules)).
+- [Configurable rules](../rules/configurable-rules.md) so that you can build your own rules following common patterns
+- [Custom plugins](../custom-plugins/index.md) for advanced users that need additional functionality
+
+## Lint an existing Open-RPC file
+
+Redocly CLI takes its settings from a `redocly.yaml` configuration file.
+Below is an example of a simple configuration file for validating an Open-RPC file is in the expected format:
+
+```yaml
+rules:
+  struct: error
+```
+
+The empty `extends` element instructs Redocly CLI not to use any existing rulesets, but to display an error if the `struct` rule finds any problem.
+This rule checks that the document structure matches the Open-RPC specification.
+
+With this configuration file, and your Open-RPC description file, run the linting command:
+
+```sh
+redocly lint open-rpc.json
+```
+
+The output describes any structural problems with the document, or reports that it is valid.
+
+## Open-RPC rules
+
+To expand the linting checks for an Open-RPC description, start by enabling some of the built-in rules.
+The currently supported rules are:
+
+- `no-unresolved-refs`: Every `$ref` must exist.
+- `no-unused-components`: All components must be used.
+- `spec-no-duplicated-method-params`: The list of parameters must not include duplicated parameters.
+- `spec-no-required-params-after-optional`: Required parameters must be positioned before optional parameters.
+- `info-contact`: Contact section is defined under `info`.
+- `info-license`: License section is defined under `info`.
+
+We expect the list to expand over time, so keep checking back - and let us know if you have any requests by [opening an issue on the GitHub repo](https://github.com/Redocly/redocly-cli/issues).
+
+To use a rule in your own linting setup, add the rule name to the `rules` configuration section, and declare the severity level (either `error`, `warn` or `off`).
+Here's an example of a rules block where a missing contact section causes a warning, and a tag without a description triggers an error:
+
+```yaml
+rules:
+  info-contact: warn
+  info-license: error
+```
+
+Pick and mix the available rules until you have the setup that fits your situation.
+
+## Configurable rule example
+
+Redocly CLI also offers [configurable rules](../rules/configurable-rules.md) that allow you to set assertions about the API description being linted. This functionality works for Open-RPC too.
+The following example shows a configurable rule that displays a warning if the `title` field is not present in the `info` block:
+
+```yaml
+rules:
+  rule/info-title:
+    subject:
+      type: Info
+      property: title
+    assertions:
+      defined: true
+    severity: warn
+```
+
+With the extensive configurable rules options available, there are many opportunities to make sure that your Open-RPC spec conforms with expectations. We'd also love to see what you're building - it helps us know how things are going!
+
+{% admonition type="info" name="Custom plugins" %}
+To create your own plugins, see the [custom plugins documentation](../custom-plugins/index.md).
+
+{% /admonition %}

docs/@v2/rules.md

@@ -9,7 +9,7 @@ Redocly uses rules to describe all the different aspects of API behavior that we
 
 - **Rulesets** are groups of rules that can be applied to any API. This is a good way to build up a ruleset that you can use locally or with your CI. Multiple rulesets can be used at once, so feel free to make smaller ones and compose the rulesets that fit each API.
 - **Built-in rules:** for the most common use cases, the rules are already made for you, all you need to do is choose if they should cause an `error`, simply `warn` of a problem, or be turned `off`. [See the built-in rules documentation](./rules/built-in-rules.md) for more information and examples.
-- **Configurable rules** allow powerful describing of API standards without needing to write code. Create a configurable rule, choose which parts of the OpenAPI description it applies to, and what the criteria for success are. The linting tool does the rest. With plenty of examples, the [configurable rules](./rules/configurable-rules.md) helps you to describe your API standards easily and well.
+- **Configurable rules** allow powerful describing of API standards without needing to write code. Create a configurable rule, choose which parts of the API description it applies to, and what the criteria for success are. The linting tool does the rest. With plenty of examples, the [configurable rules](./rules/configurable-rules.md) helps you to describe your API standards easily and well.
 - **Custom code rules** if none of the above exactly fits your needs, then a [custom code plugin](./custom-plugins/index.md) is an extensible way to bring some custom JavaScript to build on Redocly's existing features.
 
 ## Rulesets

docs/@v2/rules/built-in-rules.md

@@ -20,6 +20,7 @@ Redocly CLI can lint multiple API description formats:
 - [OpenAPI](#openapi-rules)
 - [AsyncAPI](#asyncapi-rules)
 - [Arazzo](#arazzo-rules)
+- [Open-RPC](#open-rpc-rules)
 - Overlay
 
 Visit each page for details of what the rule does, additional configuration options, and examples of it in use.
@@ -148,6 +149,18 @@ The below rules are being migrated to Respect:
 - [x-security-scheme-name-reference](./respect/x-security-scheme-name-reference.md): when multiple `sourceDescriptions` exist, `workflow.x-security.schemeName` must reference a source description (for example, `$sourceDescriptions.{name}.schemeName`)
 - [x-security-scheme-required-values](./respect/x-security-scheme-required-values.md) validate that `x-security` have all required `values` described according to the used `scheme`.
 
+## Open-RPC rules
+
+Use the rules in this section for Open-RPC specific linting.
+
+- [struct](./common/struct.md): Conform to the declared Open-RPC specification version
+- [no-unresolved-refs](./common/no-unresolved-refs.md): Every `$ref` must exist
+- [no-unused-components](./oas/no-unused-components.md): All components must be used
+- `spec-no-duplicated-method-params`: The list of parameters must not include duplicated parameters
+- `spec-no-required-params-after-optional`: Required parameters must be positioned before optional parameters
+- [info-contact](./oas/info-contact.md): Contact section is defined under `info`
+- [info-license](./oas/info-license.md): License section is defined under `info`
+
 ## Resources
 
 - Learn more about [API linting](../api-standards.md), or follow the [guide to configuring a ruleset](../guides/configure-rules.md).

packages/cli/src/__tests__/fixtures/config.ts

@@ -25,6 +25,7 @@ export const configFixture: Config = {
     async3: {},
     arazzo1: {},
     overlay1: {},
+    openrpc1: {},
   },
   preprocessors: {
     oas2: {},
@@ -35,6 +36,7 @@ export const configFixture: Config = {
     async3: {},
     arazzo1: {},
     overlay1: {},
+    openrpc1: {},
   },
   plugins: [],
   doNotResolveExamples: false,
@@ -47,6 +49,7 @@ export const configFixture: Config = {
     async3: {},
     arazzo1: {},
     overlay1: {},
+    openrpc1: {},
   },
   resolveIgnore: vi.fn(),
   addProblemToIgnore: vi.fn(),

packages/cli/src/__tests__/utils.test.ts

@@ -546,6 +546,7 @@ describe('checkIfRulesetExist', () => {
       async3: {},
       arazzo1: {},
       overlay1: {},
+      openrpc1: {},
     };
     expect(() => checkIfRulesetExist(rules)).toThrowError(
       '⚠️ No rules were configured. Learn how to configure rules: https://redocly.com/docs/cli/rules/'
@@ -562,6 +563,7 @@ describe('checkIfRulesetExist', () => {
       async3: {},
       arazzo1: {},
       overlay1: {},
+      openrpc1: {},
     };
     checkIfRulesetExist(rules);
   });