Update json_schemer requirement from >= 0.2.1, < 0.2.19 to >= 0.2.1, < 2.0.1

[dependabot]

Updates the requirements on json_schemer to permit the latest version.

Changelog

Sourced from json_schemer's changelog.

2.0.0 - XXXX-XX-XX

For 2.0.0, much of the codebase was rewritten to simplify support for the two new JSON Schema draft versions (2019-09 and 2020-12). The major change is moving each keyword into its own class and organizing them into vocabularies. Output formats and annotations from the new drafts are also supported. The known breaking changes are listed below, but there may be others that haven't been identified.

Breaking Changes

• The default meta schema is now Draft 2020-12. Other meta schemas can be specified using meta_schema.
• Schemas use json-schemer://schema as the default base URI. Relative $id and $ref values are joined to the default base URI and are always absolute. For example, the schema { '$id' => 'foo', '$ref' => 'bar' } uses json-schemer://schema/foo as the base URI and passes json-schemer://schema/bar to the ref resolver. For relative refs, URI#path can be used in the ref resolver to access the relative portion, ie: URI('json-schemer://schema/bar').path => "/bar".
• Property validation hooks (before_property_validation and after_property_validation) run immediately before and after properties validation. Previously, before_property_validation ran before all "object" validations (dependencies, patternProperties, additionalProperties, etc) and after_property_validation was called after them.
• insert_property_defaults now inserts defaults in conditional subschemas when possible (if there's only one default or if there's only one unique default from a valid subtree).
• Error output
  • Special characters in schema_pointer are no longer percent encoded (eg, definitions/foo\"bar instead of /definitions/foo%22bar)
  • Keyword validation order changed so errors may be returned in a different order (eg, items errors before contains).
  • Array dependencies return "type": "dependencies" errors instead of "required" and point to the schema that contains the dependencies keyword.
  • not errors point to the schema that contains the not keyword (instead of the schema defined by the not keyword).
  • Custom keyword errors are now always wrapped in regular error hashes. Returned strings are used to set type:

    >> JSONSchemer.schema({ 'x' => 'y' }, :keywords => { 'x' => proc { false } }).validate({}).to_a
    => [{"data"=>{}, "data_pointer"=>"", "schema"=>{"x"=>"y"}, "schema_pointer"=>"", "root_schema"=>{"x"=>"y"}, "type"=>"x"}]
    >> JSONSchemer.schema({ 'x' => 'y' }, :keywords => { 'x' => proc { 'wrong!' } }).validate({}).to_a
    => [{"data"=>{}, "data_pointer"=>"", "schema"=>{"x"=>"y"}, "schema_pointer"=>"", "root_schema"=>{"x"=>"y"}, "type"=>"wrong!"}]
    

1.0.0 - 2023-05-26

Breaking Changes

• Ruby 2.4 is no longer supported.
• The default regexp_resolver is now ruby, which passes patterns directly to Regexp. The previous default, ecma, rewrites patterns to behave more like Javascript (ECMA-262) regular expressions:
  • Beginning of string: ^ -> \A
  • End of string: $ -> \z
  • Space: \s -> [\t\r\n\f\v\uFEFF\u2029\p{Zs}]
  • Non-space: \S -> [^\t\r\n\f\v\uFEFF\u2029\p{Zs}]
• Invalid ECMA-262 regular expressions raise JSONSchemer::InvalidEcmaRegexp when regexp_resolver is set to ecma.
• Embedded subschemas (ie, subschemas referenced by $id) can only be found under "known" keywords (eg, definitions). Previously, the entire schema object was scanned for $id.
• Empty fragments are now removed from $ref URIs before calling ref_resolver.
• Refs that are fragment-only JSON pointers with special characters must use the proper encoding (eg, "$ref": "#/definitions/some-%7Bid%7D").

Commits

• e15c5b4 Merge pull request #135 from davishmcclurg/next
• db29755 2.0.0
• 24ac3bf Move some special keyword classes to constants
• 282341d Add helper for converting enumerators to arrays
• 1f19ca6 Allow exclusive refs into sibling definitions
• 410c3d7 Support schema bundling
• ec38c92 Add classic output format to benchmark
• 07f40f7 Test meta schemas match what's published
• a705629 Add Schema#ref helper
• 70a7956 OpenAPI 3.0
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[chef-expeditor]

Hello dependabot[bot]! Thanks for the pull request!

Here is what will happen next:

1. Your PR will be reviewed by the maintainers.
2. Possible Outcomes
   a. If everything looks good, one of them will approve it, and your PR will be merged.
   b. The maintainer may request follow-on work (e.g. code fix, linting, etc). We would encourage you to address this work in 2-3 business days to keep the conversation going and to get your contribution in sooner.
   c. Cases exist where a PR is neither aligned to Chef InSpec's product roadmap, or something the team can own or maintain long-term. In these cases, the maintainer will provide justification and close out the PR.

Thank you for contributing!