-
Notifications
You must be signed in to change notification settings - Fork 18
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
UX improvement: using real config file as spec and with --all-required flag #47
Comments
(@abonander Thanks much for your input, here and in the other issues you have entered. I'm currently on vacation but will take a closer look in a couple of weeks. Thanks again.) |
As just committed, the new |
We've been using Typesafe-Config at work in a few projects now and we really like it; we've actually written very similar boilerplate code to what this library generates, and now having stumbled across it I'd like to use it instead.
However, because we've been using Config directly, all we have are actual config files that act as both reference/template and default; I am aware they can be used directly as specs for codegen with this tool but it generates code that assumes any given values in the config files are the defaults when I would like to just have them all be required values (so if they're modified later but a key is omitted or mistyped it throws an error instead of falling back to default).
I see this has already been sort-of discussed in #43 but I would say this is the "application" workflow that was mentioned; I would like to just use the default config as the spec, otherwise it's two separate files to keep in sync with each other with duplicated structure but one contains types while the other contains values.
I think this could be implemented as a flag like
--assume-all-required
or something which doesn't pull default values from the spec; it just uses them to infer the types of the fields.The text was updated successfully, but these errors were encountered: