One of Nickel's core selling point is correctness. Thanks to type, contracts and metadata, Nickel makes many information part of the language itself, such that this information can be leveraged by various tools to provide benefit.
Currently, contract failures are expected to give nice error messages when one tries to evaluate a faulty Nickel configuration. However, as opposed to static types, there is currently no feedback when writing code through the LSP. The reason is that contracts are by nature dynamic, and they require to run Nickel code, while types are static and are checked before the program even runs.
Still, the in-editor experience in a cornerstone of the improved developer experience that Nickel should provide, thus contracts failure should be reported as early as possible, even while the configuration is being written.
Expected outcome
Implementing contract check in the LSP would greatly improve the developer experience, tightening the feedback loop, and make the developer experience a strong selling point.
Proposal
A first, simple step is to add a code action to run the whole configuration and render the diagnostics in the editor. The long-term vision would be to perform partial evaluation in the background to gradually report any contract violation that can be (i.e. that doesn't rely on yet-unknown-values).
Check contract applications in the LSP
One of Nickel's core selling point is correctness. Thanks to type, contracts and metadata, Nickel makes many information part of the language itself, such that this information can be leveraged by various tools to provide benefit.
Currently, contract failures are expected to give nice error messages when one tries to evaluate a faulty Nickel configuration. However, as opposed to static types, there is currently no feedback when writing code through the LSP. The reason is that contracts are by nature dynamic, and they require to run Nickel code, while types are static and are checked before the program even runs.
Still, the in-editor experience in a cornerstone of the improved developer experience that Nickel should provide, thus contracts failure should be reported as early as possible, even while the configuration is being written.
Expected outcome
Implementing contract check in the LSP would greatly improve the developer experience, tightening the feedback loop, and make the developer experience a strong selling point.
Proposal
A first, simple step is to add a code action to run the whole configuration and render the diagnostics in the editor. The long-term vision would be to perform partial evaluation in the background to gradually report any contract violation that can be (i.e. that doesn't rely on yet-unknown-values).
Related:
1501