If you would like to contribute to this project please read the contributing guidelines.
- You are welcome to submit an issue with a bug report or a feature request.
- If you are reporting a bug, please indicate which version of the package you are using and provide steps to reproduce the problem.
- If you are submitting a feature request, please indicate if you are willing or able to submit a PR for it.
To build and test the project locally, clone the repo and issue the following commands
npm install
npm test
When you add a new rule there are a number of places you should consider including:
spectral.yaml
should define the new rule, possibly pointing to a new function used by the rule.functions
directory to hold any new function for the rule.test\<rulename>.test.js
should test at least the error and no-error cases of the rule.openapi-style-guide.md
should be updated with the style guideline that the rule enforces.
When creating new rules we have some conventions that should be followed. For rule properties:
Field | Notes |
---|---|
name | prefixes: |
"tdp- " Trimble Developer Program |
|
"tas- /tapi " Trimble API Standards |
|
formats | You can add formats, however, tdp has a warning rule on oas formats lower than 3.0 |
Rule name convention, not really strict about this, but it should be something like:
{prefix}-{target}-{rule}
Where
- prefix, origin of this rule, tdp or tas
- target, what part of the spec does the rule apply to,
tag
,path
,operation
, etc. or compound liketag-description
oroperation-params
- rule, extremely concise rule description, like
camel-case
,no-versions
,no-refs
, etc.
When adding a new rule, please add a section to the style guide that describes the rule. The section heading should match the rule name in the spectral.yaml
file. For example, if the rule name is tdp-tag-pascal-case
then the section should be ### tdp-tag-pascal-case
.