Gathering detailed insights and metrics for @stoplight/spectral-ruleset-migrator
Gathering detailed insights and metrics for @stoplight/spectral-ruleset-migrator
Gathering detailed insights and metrics for @stoplight/spectral-ruleset-migrator
Gathering detailed insights and metrics for @stoplight/spectral-ruleset-migrator
A flexible JSON/YAML linter for creating automated style guides, with baked in support for OpenAPI (v3.1, v3.0, and v2.0), Arazzo v1.0, as well as AsyncAPI v2.x.
npm install @stoplight/spectral-ruleset-migrator
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
2,551 Stars
2,098 Commits
240 Forks
34 Watching
22 Branches
157 Contributors
Updated on 28 Nov 2024
TypeScript (96.98%)
JavaScript (2.68%)
HTML (0.17%)
Shell (0.1%)
Dockerfile (0.07%)
Cumulative downloads
Total Downloads
Last day
-7.8%
63,619
Compared to previous day
Last week
0.3%
367,458
Compared to previous week
Last month
20.1%
1,440,019
Compared to previous month
Last year
17.7%
13,489,552
Compared to previous year
14
The easiest way to install spectral is to use either npm:
1npm install -g @stoplight/spectral-cli
Or yarn:
yarn global add @stoplight/spectral-cli
There are also additional installation options.
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, Arazzo or AsyncAPI:
1echo 'extends: ["spectral:oas", "spectral:asyncapi", "spectral:arazzo"]' > .spectral.yaml
If you would like to create your own rules, check out the Custom Rulesets page.
Use this command if you have a ruleset file in the same directory as the documents you are linting:
1spectral lint myapifile.yaml
Use this command to lint with a custom ruleset, or one that's located in a different directory than the documents being linted:
1spectral lint myapifile.yaml --ruleset myruleset.yaml
Once you've had a look through the getting started material, some of these guides can help you become a power user.
If you need help using Spectral or have any questions, you can use GitHub Discussions, or visit the Stoplight Community Discord. These communities are a great place to share your rulesets, or show off tools that use Spectral.
If you have a bug or feature request, create an issue for it.
Stoplight has a set of Spectral rulesets that were created to help users get started with Stoplight's Style Guides. You can find them on API Stylebook, and you can download the source Spectral file by selecting a style guide on the project sidebar and selecting Export -> Spectral File(s) on the top-right. A few noteworthy style guides are:
There are also rulesets created by many companies to improve their APIs. You can use these as is to lint your OpenAPI descriptions, or use these as a reference to learn more about what rules you would want in your own ruleset:
$ref
(probably to minimize conflicts), naming conventions for Operation IDs, and all sorts of other handy OpenAPI tips.application/json
.Check out some additional style guides here:
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 🎉
If you are interested in contributing to Spectral, check out CONTRIBUTING.md.
Spectral is 100% free and open-source, under Apache License 2.0.
If you would like to thank Stoplight for creating Spectral, buy the world a tree.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
30 commit(s) and 5 issue activity found in the last 90 days -- score normalized to 10
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
6 existing vulnerabilities detected
Details
Reason
Found 3/27 approved changesets -- score normalized to 1
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
Project has not signed or included provenance with any releases.
Details
Reason
security policy file not detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More