Need help? Have a question? Want to share your work? Join our discord and
come say hi!
Documentation
🔥 New inv0.12+ 🔥 : Core functions support JSON Path.
Now all core functions return the correct and accurate JSON path for each linting result. Previously this was not possible
at all, but with some clever engineering, we have made it happen. It's a small thing, but with huge impact.
This feature has been available on the OpenAPI functions for some time, however core functions were without a comparison.
But no more! core functions have joined the party.
A new --no-clip flag is available on the lint command. This prevents message/path truncation.
v0.11+: Ignore Linting Errors/Violations.
v0.11 introduces the ability to ignore specific linting errors. This is useful for when you want to implement new
rules to existing production APIs. In some cases, correcting the lint errors would result in a breaking change.
Having a way to ignore these errors allows you to implement the new rules for new APIs while maintaining
backwards compatibility for existing ones.
v0.10 is a quality release, with a number of fixes and improvements to rule schemas, function names and more.
vacuum now powers The OpenAPI doctor. To enable correct ruleset management and automation
a number of functions have been renamed, interfaces have been upgraded and rule functions schemas are now accurate.
This is a breaking change for anyone using vacuum as a library with custom rules.
v0.9+ : Built in Language Server.
A new command is available language-server. This starts vacuum as an LSP compatible language server. Run vacuum
in your favorite IDE and get linting and validation as you type, in realtime.
Will support any LSP compatible editor, like VSCode, Sublime, vim, etc.
A new linting rule is available oas-schema-check will perform type checks and validation on all schemas in your
OpenAPI file. It's enabled by default in the recommended ruleset.
vacuum can suck all the lint of a 5mb OpenAPI spec in milliseconds.
Designed to reliably lint OpenAPI specifications, very, very quickly. Including very large ones. Spectral can be quite slow
when used as an API and does not scale for enterprise applications.
vacuum will tell you what is wrong with your spec, why, where and how to fix it.
vacuum will work at scale and is designed as a CLI (with a web or console UI) and a library to be consumed in other applications.
Dashboard
vacuum comes with an interactive dashboard (vacuum dashboard <your-openapi-spec.yaml>) allowing you to explore
rules and violations in a console, without having to scroll through thousands of results.
HTML Report
vacuum can generate an easy to navigate and understand HTML report. Like the dashboard
you can explore broken rules and violations, but in your browser.
No external dependencies, the HTML report will run completely offline.
Supports OpenAPI Version 2 (Swagger) and Version 3+
You can use either YAML or JSON, vacuum supports both formats.
repos:
- repo: https://github.com/daveshanley/vacuum
rev: # a tag or a commit hash from this repo, see https://github.com/daveshanley/vacuum/releases
hooks:
- id: vacuum
See the hook definition here for details on what options the hook uses and what files it checks by default.
If no filenames or more than one filename in your repository matches the default files pattern in the hook definition,
the pattern needs to be overridden in your config so that it matches exactly one filename to lint at a time.
To lint multiple files, specify the hook multiple times with the appropriate overrides.
The report file name is optional. The default report output name is vacuum-spectral-report.json
Generate a vacuum report
Vacuum reports are complete snapshots in time of a linting report for a specification. These reports can be 'replayed'
back through vacuum. Use the dashboard or the html-report commands to 'replay' the report and explore the results
as they were when the report was generated.
The default name of the report will be vacuum-report-MM-DD-YY-HH_MM_SS.json. You can change the prefix by supplying
it as the second argument to the report command.
Ideally, you should compress the report using -c. This shrinks down the size significantly. vacuum automatically
recognizes a compressed report file and will deal with it automatically when reading.
When using compression, the file name will be vacuum-report-MM-DD-YY-HH_MM_SS.json.gz. vacuum uses gzip internally.
Ignoring specific linting errors
You can ignore specific linting errors by providing an --ignore-file argument to the lint and report commands.
Ignoring errors is useful for when you want to implement new rules to existing production APIs. In some cases,
correcting the lint errors would result in a breaking change. Having a way to ignore these errors allows you to implement
the new rules for new APIs while maintaining backwards compatibility for existing ones.
Try out the dashboard
This is an early, but working console UI for vacuum. The code isn't great, it needs a lot of clean up, but
if you're interested in seeing how things are progressing, it's available.