Lint and format

The review comments a linter writes for you

Reviewers keep flagging missing descriptions, unbounded strings and inconsistent names. Put those checks in a ruleset, and the linter catches them before the review.

Lint your first file Install API Genie

Reviews about the API, not the YAMLMissing descriptions, unbounded strings and inconsistent names are caught before a reviewer sees them, and the formatter ends the arguments about indentation and key order.
Your Spectral rules carry overHouse rules written for Spectral mostly carry over: the core functions are built in, and most custom functions run unchanged in the CLI. Aliases and script expressions don't, and the editor runs no custom functions.
Fixes, not only findingsapigenie lint --fix fixes the issues that have a safe fix, and keeps the comments of your files.

What the linter says about a file

Each issue names its line, its severity and its rule: here a parameter named against the convention, an operation without a description and a string with no length limit. The command exits with status 1 when it finds errors, and format --check when a file isn't formatted.

$ apigenie lint orders.yaml
  12:5   warning  Tag 'orders' has no meaningful description defined                tag-description-defined
  17:9   warning  Parameter should be named order_id                                parameter-naming
  25:7   error    Operation has no meaningful description                           operation-description-defined
  62:11  warning  String schema does not define constraints restricting its length  schema-constraints

  4 issues (1 errors, 3 warnings)
$ apigenie format --check orders.yaml

What it covers

Five lintersRules and rulesets for OpenAPI, AsyncAPI, Swagger 2.0, GraphQL and Protobuf.
Custom rulesThe recommended and strict rulesets, severities changed in apigenie.yaml, and your own rules in Spectral's given, then and JSONPath form.
Reports for CISARIF for code scanning, JUnit, checkstyle, TAP, JSON and HTML.
A formatter that keeps meaningIndentation, key order and YAML styles; formatting twice gives the same file.
In the editorThe same rules under the fields of the editor's forms, with one-click fixes.
In pull requestsThe GitHub Action shows the issues on the changed lines.

The tools that do it

Step by step

Lint and format API descriptions: Give every API description of a repository the same rules and the same style, locally and in every pull request.

Start with the rules you have

The recommended ruleset needs no configuration, and most Spectral rules carry over; the reference lists what doesn't. Lint one file today; add the check to CI when it passes.