This:
- Updates the README with the new rules (and recommendations)
- Updates `keyword.js` to implement the agreed change to the naming rules:
- - Now same as before but also allow hyphens as second and subsequent characters
- Update tests to test the new keyword naming rules
- Update `definitions.def` to use it.util.getProperty() to dynamically choose dot
or bracket notation as appropriate rather than hardcode bracket notation.
Test Plan:
- Run `npm test` and ensure all tests run and pass
Custom keywords were required to be valid JS identifiers due to the
way they were being used in the generated code. This prevented the use
of keywords with the `x-` prefix that is required by [swagger](http://swagger.io].
This change fixes that by updating the only place that was using them
directly as an identifier to use //brackets// notation rather than
//dot// notation. This brings the definition of `$schemaPath` in
`definitions.def` in line with the way the rule definition is accessed
from `RULES.custom` at the top of `custom.jst`.
The validation of the keyword name has been changed to allow any name
in this change, but this should be updated to either just remove the
test or update it to a new rule before this change is included in
the project.
Finally, this also updates a number of the tests in `custom.spec.js` to
use non-valid identifiers for the names of some of the custom keywords
being tested (primarily by adding `x-` to the front of the name).
Test Plan:
- Run `npm test` and ensure all tests run and pass
allow boolean schemas
async validation promise resolves with data
properties of custom keyword definition ($data and metaSchema)
custom keyword schema can be any value
keyword schema in error object can be any value
optional propertyName property of error object for all keywords (added when validating schema in propertyNames)
propertyNames keyword error params
Idan Gozlan