feat(ruleset): add asyncapi2 ruleset (#974)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -13,7 +13,7 @@ A clear and concise description of what the bug is.
 
 **To Reproduce**
 
-1. Given this OpenAPI document '...'
+1. Given this OpenAPI/AsyncAPI document '...'
 2. Run this CLI command '....'
 3. See error
 

README.md

@@ -4,14 +4,16 @@
 [![NPM Downloads](https://img.shields.io/npm/dw/@stoplight/spectral?color=blue)](https://www.npmjs.com/package/@stoplight/spectral)
 [![Treeware (Trees)](https://img.shields.io/treeware/trees/stoplightio/spectral)](https://plant.treeware.earth/stoplightio/spectral)
 
-A flexible JSON/YAML linter, with out of the box support for OpenAPI v2 and v3.
+A flexible JSON/YAML linter, with out of the box support for OpenAPI v2/v3 and AsyncAPI v2.
 
 ![Demo of Spectral linting an OpenAPI document from the CLI](./docs/img/demo.svg)
 
 ## Spectral Features
 
 - Create custom rules to lint JSON or YAML objects
-- Ready to use rules to validate and lint OpenAPI v2 _and_ v3 documents
+- Ready-to-use rules to validate and lint:
+  - OpenAPI v2 _and_ v3 documents
+  - AsyncAPI v2 documents
 - Use JSON path to apply rules to specific parts of your objects
 - Built-in set of functions to help [create custom rules](https://stoplight.io/p/docs/gh/stoplightio/spectral/docs/getting-started/rulesets.md#adding-a-rule). Functions include pattern checks, parameter checks, alphabetical ordering, a specified number of characters, provided keys are present in an object, etc.
 - Create custom functions for advanced use cases

docs/getting-started/asyncapi.md

@@ -0,0 +1,5 @@
+# AsyncAPI Support
+
+Spectral is a generic linter, but a lot of effort has been put in to making sure [AsyncAPI v2](https://www.asyncapi.com/docs/specifications/2.0.0/) is well supported.
+
+Run Spectral against a document without specifying a ruleset will trigger an auto-detect, where Spectral will look to see if `asyncapi: 2.0.0` is in the root of the document. If it finds it, it will load `spectral:asyncapi`, which is documented in our [Reference > AsyncAPI Rules](../reference/asyncapi-rules.md).

docs/getting-started/concepts.md

@@ -18,6 +18,6 @@ Rules can be comprised of one of more functions, to facilitate any style guide.
 - Tags must be plural
 - Tags must be singular
 
-Spectral comes bundled with a [bunch of functions](../reference/functions.md) and a default style guide for [OpenAPI v2 and v3](./openapi.md), which you can extend, cherry-pick, or disable entirely.
+Spectral comes bundled with a [bunch of functions](../reference/functions.md) and default style guides for [OpenAPI v2 and v3](./openapi.md) and [AsyncAPI v2](./asyncapi.md), which you can extend, cherry-pick, or disable entirely.
 
 Learn more about [rulesets](./rulesets.md).

docs/getting-started/openapi.md

@@ -2,7 +2,7 @@
 
 Spectral is a generic linter, but a lot of effort has been put in to making sure OpenAPI is well supported.
 
-Run Spectral against a document without specifying a ruleset will trigger an auto-detect, where Spectral will look to see if `swagger: 2.0` or `openapi: 3.0.x` is at the top of the file. If it finds either of those it will load `spectral:oas`, which is documented in our [Reference > OpenAPI Rules](../reference/openapi-rules.md).
+Run Spectral against a document without specifying a ruleset will trigger an auto-detect, where Spectral will look to see if `swagger: 2.0` or `openapi: 3.0.x` are in the root of the document. If it finds either of those it will load `spectral:oas`, which is documented in our [Reference > OpenAPI Rules](../reference/openapi-rules.md).
 
 <!-- theme: info -->
-> If you would like support for other API description formats like [RAML](https://raml.org/), message formats like [JSON:API](https://jsonapi.org/), event-driven API descriptions like [AsyncAPI](https://asyncapi.io/), etc., we recommend you start building custom but generic rulesets which can be shared with others. We've started putting together some over here on [OpenAPI Contrib](https://github.com/openapi-contrib/style-guides/).
+> If you would like support for other API description formats like [RAML](https://raml.org/), message formats like [JSON:API](https://jsonapi.org/), etc., we recommend you start building custom but generic rulesets which can be shared with others. We've started putting together some over here on [OpenAPI Contrib](https://github.com/openapi-contrib/style-guides/).

docs/getting-started/rulesets.md

@@ -117,6 +117,7 @@ Formats are an optional way to specify which API description formats a rule, or
 - `json-schema-draft6` (this is JSON Schema Draft 6, detection based on the value of $schema property)
 - `json-schema-draft7` (this is JSON Schema Draft 7, detection based on the value of $schema property)
 - `json-schema-2019-09` (this is JSON Schema 2019-09, detection based on the value of $schema property)
+- `asyncapi2` (this is AsyncAPI v2.0.0)
 
 Specifying the format is optional, so you can completely ignore this if all the rules you are writing apply to any document you lint, or if you have specific rulesets for different formats. If you'd like to use one ruleset for multiple formats, the formats key is here to help.
 
@@ -167,6 +168,10 @@ Custom formats can be registered via the [JS API](../guides/javascript.md), but
 
 Rulesets can extend other rulesets using the `extends` property. This can be used to build upon or customize other rulesets.
 
+_Note:_ Spectral core rulesets are
+ - `spectral:oas`: OpenAPI v2/v3 rules
+ - `spectral:asyncapi`: AsyncAPI v2 rules
+
 ```yaml
 extends: spectral:oas
 rules:
@@ -178,7 +183,7 @@ rules:
       function: truthy
 ```
 
-The example above will apply the core rules from the built in OpenAPI v2 ruleset AND apply the custom `my-rule-name` rule.
+The example above will apply the core rules from the built in OpenAPI v2/v3 ruleset AND apply the custom `my-rule-name` rule.
 
 Extends can be a single string or an array of strings, and can contain either local file paths or URLs.
 
@@ -248,6 +253,7 @@ rules:
 The example above will run all of the rules defined in the `spectral:oas` ruleset (rather than the default behavior that runs only the recommended ones), with one exceptions - we turned `operation-operationId-unique` off.
 
 - [Rules relevant to OpenAPI v2 and v3](../reference/openapi-rules.md)
+- [Rules relevant to AsyncAPI v2](../reference/asyncapi-rules.md)
 
 ## Selectively silencing some results
 

docs/guides/cli.md

@@ -43,7 +43,9 @@ The Spectral CLI supports loading documents as YAML or JSON, and validation of O
 
 You can also provide your own ruleset file. By default, the Spectral CLI will look for a ruleset file called `.spectral.yml` or `.spectral.json` in the current working directory. You can tell spectral to use a different file by using the `--ruleset` CLI option.
 
-Here you can build a [custom ruleset](../getting-started/rulesets.md), or extend and modify our [core OpenAPI ruleset](https://stoplight.io/p/docs/gh/stoplightio/spectral/docs/reference/openapi-rules.md).
+Here you can build a [custom ruleset](../getting-started/rulesets.md), or extend and modify our core rulesets:
+- [OpenAPI ruleset](../reference/openapi-rules.md)
+- [AsyncAPI ruleset](../reference/asyncapi-rules.md)
 
 ## Error Results