-
Notifications
You must be signed in to change notification settings - Fork 92
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
Allow fully validating and checking formatting of nickel files without evaluation #2028
Comments
There's a |
I'm aware of |
Can you give an example of the sort of error you'd like to catch but isn't caught by |
As an example:
|
Well, this isn't a syntax error per se - the syntax allows to apply pretty much any value to any other value. In a fully statically typed language, that would be caught by the typechecker. This is obviously not the case for the parts that are dynamically typed in Nickel. However, I reckon that this precise kind of error should be easy to detect statically. As typechecking already walks the AST for various purposes, maybe we should also check that the head (the left part) of an application isn't something that has no chance of ever making sense (typically any literal - record, array, number, string, boolean, etc.). Of course, once you do something more elaborate such as |
However you call it, I would like to be able to validate configuration in such a way that I know it won't cause any errors during eval/export. |
If you want to catch all possible eval/export errors, I think you just have to do a full eval/export. There are evaluation-time errors (like evaluation-time contract failures) that don't get caught by any other phase. |
As a side note, the strict mode proposed in #2049 could help detect those kind of errors as well (I mean, static typing in general). Otherwise, as Joe says, there's a whole class of validation errors that you just can't check statically in general. The bad application stuff is still something that might be worth checking maybe during the walk mode of the typechecker; I'm keeping this issue open for the latter to be implemented. |
Is your feature request related to a problem? Please describe.
There is currently no way to validate that a nickel configuration file is free of type and syntax errors without fully evaluating it.
The same goes for formatting, it is not possible to only check if a file is formatted correctly, without actually performing the formatting.
Describe the solution you'd like
A
validate
subcommand that ensures a nickel file is free of type or syntax errors, essentially aneval
without the actual full evaluation and output. To check formatting, something likenickel format --check config.ncl
would be great.Describe alternatives you've considered
I currently use
nickel eval config.ncl > /dev/null
to check for errors.Since
nickel format
returns the same exit code whether it did something or not, the only way I can come up with to validate formatting is to actually runnickel format config.ncl
and checking if the file was changed.The text was updated successfully, but these errors were encountered: