New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global configuration options #170
Conversation
@davishmcclurg just made another round of updates and added tests for each configuration option. lmk if you have any feedback! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! Sorry for the delay on getting it reviewed.
Do you mind rebasing on the 2.2.0 branch? That's where I'm keeping everything for the next release.
hey sorry for the huge delay, been a busy few weeks 😓 will do another pass and incorporate all the feedback this weekend 🙏🏽 |
@omkarmoghe are you still planning to work on this? no worries if not—just let me know and I can finish it up. |
Don't want to introduce new behavior.
I don't think there's a good reason to change this.
It doesn't make sense in the context of the configuration object.
Match the option names from `JSONSchemer.schema` and `Schema.new`.
I want to introduce this separately and think about using it elsewhere.
This is already handled in `Schema#initialize`.
`meta_schema` is a little wrong at this point because `JSONSchemer.schema` processes strings and the configuration object only allows `Schema` objects.
This allows string values in `Configuration#meta_schema` in order to be consistent with `JSONSchemer.schema`. There's a slight behavior change in that unknown `meta_schema` values will be passed to the provided ref resolver. I think this is good because it better matches the behavior of the `$schema` keyword. `UnsupportedMetaSchema` is gone; `UnknownRef` will be raised instead. It was necessary to add `$schema` in `test_schema_validation_parse_error_with_custom_meta_schema` because `ref_resolver` schemas inherit the provided `meta_schema`, which meant the custom meta schema was using itself as a meta schema when provided as a string.
This makes it easy to pass in an existing configuration object and override multiple arguments without modifying the global configuration. It also provides a simpler way to pass configuration to subschemas (and ref schemas). `base_uri`, `meta_schema`, `ref_resolver`, and `regexp_resolver` still need to be passed separately because they're parsed and modified in the schema object (not reflected in the configuration object).
simplecov is complaining about this now for some reason. Previously, `errors_test.rb` wasn't showing up at all on the coverage report...
This makes `Configuration` a struct and overrides its `initialize` method to provide defaults. It simplifies things a bit and allows passing options during initialization using keyword arguments.
Make sure the options are actually getting applied properly.
Thanks for the contribution, @omkarmoghe! |
Forgot to add this as part of: #170
Hey sorry for the delay here, apologies for not getting back to you, totally cool with you making any of the style changes you suggested to confirm with the rest of the repo style as well. Haven't had much free time these past couple weeks to close the loop on this. 🙏🏽 |
PR for #162