@zapier/spectral-api-ruleset

@zapier/spectral-api-ruleset

Node package for linting API schemas using Spectral.

Ownership • Features • Installation • Usage • Exemptions • Development • Testing

Ownership

#team-staff-engineering owns the API Design Guidelines and these spectral rules that help teams align with them.

MRs are always welcome!

Features

Provides a Spectral linting ruleset to lint OpenAPI schemas against Zapier's API Design Guidelines.

Installation

pnpm add -D @stoplight/spectral-cli
pnpm add -D @zapier/spectral-api-ruleset

For some reason, installing the CLI globally and running spectral lint or npx spectral lint always fails to find the package. Adding the CLI as a local dependency and then running pnpm exec spectral lint does work.

Usage

CLI

There are a few ways you can use this ruleset in your projects.

You can load the ruleset in a few different ways with Spectral.

They support direct http access, via NPM, and via the local file system.

If you'd like to extend the ruleset and and even more specific rules for your API service, you can create a local spectral.yaml that extends the ruleset:

extends:
  - '@zapier/spectral-api-ruleset'

Then run:

spectral lint your-schema.yaml --ruleset .spectral.yaml

or

pnpm exec spectral lint your-schema.yaml --ruleset .spectral.yaml

or

spectral lint your-schema.yaml --ruleset https://unpkg.com/@zapier/spectral-api-ruleset@{VERSION}/.spectral.yaml

depending on whether you installed the CLI locally or globally.

See the Spectral CLI docs for more details.

CI

Use a GitLab job like the following:

openapi:lint:
  stage: validate
  before_script:
    - mkdir spectral
  script:
    - pnpm exec spectral lint your-schema.yaml -o spectral/junit.xml -f junit
  artifacts:
    when: always
    paths:
      - spectral
    reports:
      junit: spectral/junit.xml

For non-TypeScript projects, you can use the spectral docker image to avoid installing additional dependencies.

openapi:lint:
  stage: test
  image:
    name: stoplight/spectral:6.11.0
    entrypoint: [""]
  script:
    - spectral lint openapi.yaml
  only:
    - merge_requests

See Continuous Integration docs and our own openapi:lint guideance in the Engineering Index for more details.

Exemptions

Some rules in this ruleset can be exempted on a case-by-case basis with approval from #team-staff-engineering. Below are the available exemptions and how to use them.

Sorting Parameter Exemption

The zapier-sorting-parameter rule requires using order_by instead of sort_by or ordering for sorting parameters. If you need to use an alternative parameter name, you can request an exemption.

paths:
  /test:
    get:
      parameters:
        - name: sort_by
          in: query
          x-zapier-sorting-parameter-exempt: true
          description: Field to sort by

Version in Paths Exemption

The zapier-single-major-version-in-paths rule requires all paths to contain a major version (e.g., /v1/). If you need paths without versioning, you can request an exemption.

paths:
  /no-version-but-exempt:
    x-zapier-version-in-paths-exempt: true
    get:
      description: This path is exempt from versioning requirement

Auth Scheme Exemption

The zapier-allowed-auth-schemes rule requires using one of the standard Zapier authentication schemes. If you need to use a non-standard authentication scheme (e.g., legacy HMAC signatures), you can request an exemption.

components:
  securitySchemes:
    hmacSignature:
      type: apiKey
      in: header
      name: X-Signature
      x-zapier-auth-scheme-exempt: true
      description: Legacy HMAC signature scheme

Development

Setup

• Install dependencies:

pnpm install

• Run tests:

pnpm test

• Build the package:

pnpm run build

• Validate the package:

pnpm run validate

Adding Rules

You can add rules to .spectral.yaml. See the Rules docs for details.

• Provide the correct severity (error for minimal OpenAPI standard compliance, warn for "shoulds" for existing and new APIs, info for "where we want NEW APIs to be").
• Provide a clear description, as well as a documentationUrl that points to the relevant guide or guide section.
• Provide a message, which in most cases should just be {{error}}.
• Prefer Core Functions over Custom Functions.
• Include unit test(s) in tests/spectral.test.ts for all new rules.

Testing

This project uses Vitest for testing. To run the tests:

pnpm test

Publishing

GitLab CI will automatically publish the package to NPM when a merge request is merged into the main branch. Be sure to update the package version in package.json accordingly before merging.