Merge branch 'develop' into feat/expose-documentation-url

.circleci/config.yml

@@ -20,11 +20,10 @@ defaults:
  tags:
  only: /^v.*/
  node-versions: &node-versions
- - "12.22"
  - "14.21"
  - &node-maintenance-lts "16.20"
- - &node-active-lts "18.18"
- - &node-current "20.5"
+ - &node-active-lts "18.20"
+ - &node-current "20.17"
  pkg-cache-path: &pkg-cache-path /tmp/pkg-node-binaries
  ldid-version: &ldid-version 2.1.5-procursus7 # https://github.com/ProcursusTeam/ldid
 
@@ -167,7 +166,7 @@ commands:
  - run:
  name: Install ldid
  working_directory: /tmp/ldid
- command: make install
+ command: sudo make install
 
  lint-code:
  steps:
@@ -193,12 +192,12 @@ commands:
  parameters:
  max-workers:
  type: integer
- default: 2
+ default: 3
  steps:
  - run: yarn pretest
  - run:
  name: Run node tests
- command: yarn test.jest --maxWorkers=<< parameters.max-workers >>
+ command: yarn test.jest --ci --maxWorkers=<< parameters.max-workers >>
 
  test-harness:
  parameters:
@@ -212,7 +211,7 @@ commands:
  type: string
  max-workers:
  type: integer
- default: 2
+ default: 3
  steps:
  - compute-hashes
  - restore_cache:
@@ -276,7 +275,7 @@ jobs:
  - test-harness:
  os: linux
  node-version: << parameters.node-version >>
- max-workers: 2
+ max-workers: 3
 
  test-browser:
  docker:
@@ -302,7 +301,7 @@ jobs:
  - test-harness:
  os: windows
  node-version: *node-active-lts
- max-workers: 2
+ max-workers: 3
 
  build-nix-binaries:
  docker:

.eslintignore

@@ -2,5 +2,6 @@
 /test-harness/tests/
 /packages/*/dist
 /packages/rulesets/src/oas/schemas/validators.ts
+/packages/rulesets/src/arazzo/schemas/validators.ts
 /packages/*/CHANGELOG.md
 packages/formatters/src/html/templates.ts

.github/CODEOWNERS

@@ -1,9 +1,3 @@
 * @stoplightio/oss-spectral
 
-README.md @stoplightio/documentation
-
-toc.json @stoplightio/documentation
-
-/docs @stoplightio/documentation
-
 /packages/rulesets/src/asyncapi @magicmatatjahu @smoya @jonaslagoni

README.md

@@ -2,7 +2,7 @@
 [![CircleCI](https://img.shields.io/circleci/build/github/stoplightio/spectral/develop)](https://circleci.com/gh/stoplightio/spectral) [![npm Downloads](https://img.shields.io/npm/dw/@stoplight/spectral-core?color=blue)](https://www.npmjs.com/package/@stoplight/spectral-core) [![Stoplight Forest](https://img.shields.io/ecologi/trees/stoplightinc)][stoplight_forest]
 
 - **Custom Rulesets**: Create custom rules to lint JSON or YAML objects
-- **Ready-to-use Rulesets**: Validate and lint **OpenAPI v2 & v3.x** and **AsyncAPI** Documents
+- **Ready-to-use Rulesets**: Validate and lint **OpenAPI v2 & v3.x**, **AsyncAPI**, and **Arazzo v1** Documents
 - **API Style Guides**: Automated [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github.com&utm_medium=referral&utm_campaign=github_repo_spectral) using rulesets improve consistency across all your APIs
 - **Ready-to-use Functions**: Built-in set of functions to help [create custom rules](https://meta.stoplight.io/docs/spectral/e5b9616d6d50c-custom-rulesets#adding-rules). Functions include pattern checks, parameter checks, alphabetical ordering, a specified number of characters, provided keys are present in an object, etc.
 - **Custom Functions**: Create custom functions for advanced use cases
@@ -40,10 +40,10 @@ There are also [additional installation options](https://meta.stoplight.io/docs/
 
 Spectral, being a generic YAML/JSON linter, **needs a ruleset** to lint files. A ruleset is a JSON, YAML, or JavaScript/TypeScript file (often the file is called `.spectral.yaml` for a YAML ruleset) that contains a collection of rules, which can be used to lint other JSON or YAML files such as an API description.
 
-To get started, run this command in your terminal to create a `.spectral.yaml` file that uses the Spectral predefined rulesets based on OpenAPI or AsyncAPI:
+To get started, run this command in your terminal to create a `.spectral.yaml` file that uses the Spectral predefined rulesets based on OpenAPI, Arazzo or AsyncAPI:
 
 ```bash
-echo 'extends: ["spectral:oas", "spectral:asyncapi"]' > .spectral.yaml
+echo 'extends: ["spectral:oas", "spectral:asyncapi", "spectral:arazzo"]' > .spectral.yaml
 ```
 
 If you would like to create your own rules, check out the [Custom Rulesets](https://meta.stoplight.io/docs/spectral/01baf06bdd05a-rulesets) page.
@@ -114,7 +114,7 @@ Check out some additional style guides here:
 
 ## 🏁 Help Others Utilize Spectral
 
-If you're using Spectral for an interesting use case, [contact Stoplight](mailto:[email protected]) for a case study. 🎉
+If you're using Spectral for an interesting use case, create an issue with details on how you're using it. We'll add it to a list here. Spread the goodness 🎉
 
 ## 👏 Contributing
 

docs/getting-started/1-concepts.md

@@ -8,9 +8,9 @@ To achieve this, Spectral has three key concepts:
 - **Functions** accept a value and return issues if the value is incorrect.
 - **Rulesets** act as a container for rules and functions.
 
-Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md) and [AsyncAPI v2](./5-asyncapi.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI documents are valid.
+Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md), [AsyncAPI v2](./5-asyncapi.md), and [Arazzo v1](./6-arazzo.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI/Arazzo documents are valid.
 
-By far the most popular use-case of Spectral is automating [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github&utm_medium=spectral&utm_campaign=docs), implementing rules that your Architecture, DevOps, API Governance or "Center of Excellence" teams have decided upon. Companies generally write these style guides as wiki pages, and several can be found on [API Stylebook](http://apistylebook.com/), but most of these rules could be automated with Spectral. For example:
+By far the most popular use-case of Spectral is automating [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github&utm_medium=spectral&utm_campaign=docs), implementing rules that your Architecture, DevOps, API Governance, "Center for Enablement", or "Center of Excellence" teams have decided upon. Companies generally write these style guides as wiki pages, and several can be found on [API Stylebook](http://apistylebook.com/), but most of these rules could be automated with Spectral. For example:
 
 - Paths must be `/kebab-case` ([more ideas for URL rules](https://blog.stoplight.io/consistent-api-urls-with-openapi-and-style-guides))
 - HTTP Basic isn't allowed

docs/getting-started/3-rulesets.md

@@ -10,15 +10,16 @@ Rules take certain parameters and then call functions on parts of another YAML o
 
 The fastest way to create a ruleset is to use the `extends` property to leverage an existing ruleset.
 
-Spectral comes with two built-in rulesets:
+Spectral comes with three built-in rulesets:
 
 - `spectral:oas` - [OpenAPI v2/v3 rules](./4-openapi.md)
 - `spectral:asyncapi` - [AsyncAPI v2 rules](./5-asyncapi.md)
+- `spectral:arazzo` - [Arazzo v1 rules](./6-arazzo.md)
 
 To create a ruleset that extends both rulesets, open your terminal and run:
 
 ```bash
-echo 'extends: ["spectral:oas", "spectral:asyncapi"]' > .spectral.yaml
+echo 'extends: ["spectral:oas", "spectral:asyncapi", "spectral:arazzo"]' > .spectral.yaml
 ```
 
 The newly created ruleset file can then be used to lint any OpenAPI v2/v3 or AsyncAPI descriptions using the `spectral lint` command:

docs/getting-started/6-arazzo.md

@@ -0,0 +1,7 @@
+# Arazzo Support
+
+Spectral has a built-in [Arazzo v1](https://spec.openapis.org/arazzo/v1.0.0.html) ruleset that you can use to validate your Arazzo files.
+
+Add `extends: "spectral:arazzo"` to your ruleset file to apply rules for Arazzo v1.
+
+You can see a full list of the rules in this ruleset in [Arazzo Rules](../reference/arazzo-rules.md).

docs/guides/2-cli.md

@@ -27,13 +27,13 @@ spectral lint ./reference/**/*.oas*.{json,yml,yaml}
 Other options include:
 
 ```
- --version Show version number [boolean]
- --help Show help [boolean]
+ --version Show version number  [boolean]
+ --help Show help  [boolean]
  -e, --encoding text encoding to use
  [string] [choices: "utf8", "ascii", "utf-8", "utf16le", "ucs2", "ucs-2", "base64", "latin1"] [default: "utf8"]
  -f, --format formatters to use for outputting results, more than one can be provided by using
  multiple flags
- [string] [choices: "json", "stylish", "junit", "html", "text", "teamcity", "pretty", "github-actions", "sarif"]
+ [string] [choices: "json", "stylish", "junit", "html", "text", "teamcity", "pretty", "github-actions", "sarif", "markdown","gitlab"]
  [default: "stylish"]
  -o, --output where to output results, can be a single file name, multiple "output.<format>" or
  missing to print to stdout [string]
@@ -61,6 +61,7 @@ Here you can build a [custom ruleset](../getting-started/3-rulesets.md), or exte
 
 - [OpenAPI ruleset](../reference/openapi-rules.md)
 - [AsyncAPI ruleset](../reference/asyncapi-rules.md)
+- [Arazzo ruleset](../reference/arazzo-rules.md)
 
 > If you use rules created or updated in a hosted [Stoplight API project](https://docs.stoplight.io/docs/platform/branches/pam-716-updated-landing-page/c433d678d027a-create-rules) with the Spectral CLI, you must publish the project from Stoplight before rule updates are used for linting.
 

docs/guides/4-custom-rulesets.md

@@ -1,6 +1,6 @@
 # Rulesets
 
-Spectral comes with two rulesets built-in: [OpenAPI](../reference/openapi-rules.md) and [AsyncAPI](../reference/asyncapi-rules.md). They're good starting points, but the true power of Spectral comes with customizing and creating a ruleset that fits your project or organization. Creating a ruleset can help you and your team improve your API design and API development process, and help you create better APIs.
+Spectral comes with three rulesets built-in: [OpenAPI](../reference/openapi-rules.md), [AsyncAPI](../reference/asyncapi-rules.md), and [Arazzo](../reference/arazzo-rules.md). They're good starting points, but the true power of Spectral comes with customizing and creating a ruleset that fits your project or organization. Creating a ruleset can help you and your team improve your API design and API development process, and help you create better APIs.
 
 Let's look through the keywords that make up a ruleset, so you can learn how to tweak a distributed ruleset to work for you, or make your own ruleset from scratch to power your organizations [API Style Guide](https://stoplight.io/api-style-guides-guidelines-and-best-practices/?utm_source=github&utm_medium=spectral&utm_campaign=docs).
 
@@ -22,6 +22,7 @@ Rules are the most important part of a ruleset. For more details on rules and it
 
 Formats are an optional way to specify which API description formats a rule, or ruleset, is applicable to. Currently Spectral supports these formats:
 
+- `arazzo1_0` (Arazzo v1.0.x)
 - `aas2` (AsyncAPI v2.x)
 - `aas2_0` (AsyncAPI v2.0.0)
 - `aas2_1` (AsyncAPI v2.1.0)