Skip to content

JSONSchema: using a different approach for setting default userconfig values #4419

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

Open
karimkhaleel opened this issue Mar 23, 2025 · 0 comments

Comments

@karimkhaleel
Copy link
Contributor

karimkhaleel commented Mar 23, 2025

Topic

JSONSchema generation

Your thoughts

When we generate our jsonschema we need to preserve the mapping between our original go struct field names and the yaml names they get renamed to. This is done so that we can fill in the jsonschema default values from our default config object.

In order to preserve that relationship I made a fork of invopop/jsonschema, that attaches an additional OriginalPropertiesMapping field to the Schema struct. This solves our problem but adds a non jsonschema field onto the Schema struct of the jsonschema library. I don't think that this is an elegant approach and think that I came up with a better one.

I found a different way of preserving the relationship that we need during the reflection phase of the schema generation. Instead of storing that relationship on the Schema object, we can expose both the original go field name and the yaml tag name with a function similar to KeyNamer.

This + Tests would still need to get merged into the official jsonschema repo. But I think this is a more reasonable approach than the initial one I made a PR for earlier.

We would also need to make some changes on our end. This is what we would need to change our code to use the KeyNamerWithOriginalFieldName function to record the relationship between original go field names and the yaml tag names that they get exported as.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant