Ownership • Features • Installation • Usage • Development • Testing
#team-staff-engineering owns the API Design Guidelines and these spectral rules that help teams align with them.
MRs are always welcome!
Provides a Spectral linting ruleset to lint OpenAPI schemas against Zapier's API Design Guidelines.
pnpm add -D @stoplight/spectral-cli
pnpm add -D @zapier/spectral-api-ruleset
For some reason, installing the CLI globally and running
spectral lint
ornpx spectral lint
always fails to find the package. Adding the CLI as a local dependency and then runningpnpm exec spectral lint
does work.
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
or
pnpm exec spectral lint your-schema.yaml
depending on whether you installed the CLI locally or globally.
See the Spectral CLI docs for more details.
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.
See CONTRIBUTING, also for information on how we use @changesets/cli
to version and publish.
- Install dependencies:
pnpm install
- Run tests:
pnpm test
- Build the package:
pnpm run build
- Validate the package:
pnpm run validate
You can add rules to src/index.ts
. See the Alternative JS Ruleset Format docs for details.
We're using the JS format so that the package ruleset can also be used in JavaScript.
- Provide the correct
severity
(error
for musts andwarn
for shoulds). - Provide a clear
description
, as well as adocumentationUrl
that points to the relevant guide. - Provide a
message
, which in most cases should just be{{error}}
. - Prefer Core Functions over Custom Functions.
- Include a unit test for any custom functions you add to
src/functions
. - Update
tests/schema.yaml
to meet all rules (runpnpm run test:spectral
to verify). - Add failing schemas to
tests/__fixtures__
and runpnpm test integrations --updateSnapshot
to updatetest/__snapshots__/integration.test.ts.snap
and verify the found issues.
This project uses Vitest for testing. To run the tests:
pnpm test
GitLab CI will automatically publish the package to NPM when a merge request is merged into the main
branch.