Comments (5)
I like this idea. I only added the --print_validator_modules
option to be helpful in development but that was before the configuration support and names for all of the rules, etc. I don't expect it to be of any help to users and it really doesn't do much for the developer anymore either. It will be removed in a future release.
As for the --print_validator_name
feature, I'm in support of it. I can see its usefulness in mapping back to the configuration file. I think I would prefer using the word "rule" instead of "validator" since that's the naming convention we use in the documentation but that's a small detail.
One thing to note is, not all validations have a "name" that maps back into a configuration rule. There are some rules that are so basic and fundamental to the OpenAPI spec that we don't bother documenting them or making them configurable (example). This isn't a deal-breaker of course but we would want to think about what to print for the output for these cases.
As always, you are more than welcome to write a PR for this! If you are unable, I can try to look at it in the coming weeks. Thanks for the issue
from openapi-validator.
--print_rule_name ? No opinion here, whatever you think is intuitive.
Perhaps for those validations you mention above we can make up a name for them that follows a pattern, e.g. "builtin_xxxxx" where and then simply document that it is not possible to turn builtin_* rules off or something like that. I am guessing that implementing this will require adding an additional field to the JSON result object in each individual test? I suppose it will be easy enough since in the place where the test is run you are checking for the config enabling the test anyway so the string is right there.
As an FYI, I am currently writing an API validation SaaS offering and associated command line tools that will be used internally inside of VMware for API specifications across the company. We have many different APIs and lots of different legacy APIs that have their own way of doing things, so flexibility is key. Right now I am planning on spawning/calling lint-openapi from this service as a major part of the API validation. This is driving my desire for the --json option as well as the --print_rule_names and such. This service itself may end up being open source (I am pushing for this)
from openapi-validator.
@aspear I want to echo @dpopp07 and say thanks for the interest and contributions. From the beginning our goal was to create a configurable and extensible linter for OpenAPI documents, so all contributions in this spirit are welcome!
from openapi-validator.
We should evaluate the open pr that Barrett openend.
from openapi-validator.
Fixed in #44.
from openapi-validator.
Related Issues (20)
- collections missing from the openapi-ruleset in version 0.45.3 HOT 5
- Outdated info in ruleset doc HOT 5
- Support for authenticated additional Openapi definitions HOT 1
- missing-required-property rule failed at anyOf required options HOT 1
- v1.0 Community Feedback HOT 3
- Error when I use a customized rule HOT 7
- feature request: Find a way to extend the spectral default ruleset without installing it local HOT 1
- A dependency of this repository contains a critical VM escape vulnerability HOT 5
- Incorrect validation results for the ibm-parameter-casing-convention rule with camelCase HOT 3
- Support Request: how can a rule ignore parameters with a specific name? HOT 3
- ibm-etag-header crashes linter on incorrect specification HOT 4
- Failed to resolve entry for package "ibm-openapi-validator HOT 2
- Rule "ibm-success-response-example" fails for some operations but not others HOT 3
- support for RPC style HTTP calls HOT 4
- Update documentation to reflect latest recommendations HOT 4
- ibm-parameter-description rule should skip responses.links.{name}.parameters HOT 3
- Runtime error for SCIM-compliant schema (object containing $ref attribute) HOT 4
- Fix test failures with Node 20 HOT 3
- BUG: 'Enum values must be snake case' on enums like '400', '500' HOT 4
- Error running lint-openapi since v1.18.1 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openapi-validator.