We’re interested in feedback on the error messages in ReScript, especially from you here who recently came to ReScript. Error messages is a part of the language where we’d like to do more exploration, and understand better what developers are struggling with (and why). Error messages and other related things can hopefully help new users “connect the dots” quicker, and get a less frustrating starting experience with ReScript.
So, please post your thoughts, high and low. We’re interested in the raw things you struggle to understand, to identify areas we can improve, both short and long term. Please don’t hesitate to post all your feedback, even for “simple” things like “I don’t understand why I can’t add (+) thing X and thing Y together, and this error message does not help me”.
Probably not a newbie use-case but here’s an error message I’ve recently spent quite some time trying to understand: “The GADT constructor String of type S.literal
must be qualified in this pattern.”
The problem was because the classify returned the tagged variant that contained GADT literal of unknown, but expected the one of string.
type unknown
type rec literal<'value> =
| String(string): literal<string>
type tagged =
| Literal(literal<unknown>)
let classify = struct => struct.tagged
I have difficulty to explain the GADT thing, but the solution was to split the literal type into two - one with GADT and another one without for use in tagged type.
I think the one pain area I come across frequently is with
Belt.Option.getExn
My main quip is that it is impossible to tell where the exn is thrown. There is no line number, or code reference provided. If I could pass a custom exception, like getExn(#CUSTOM_ERROR_MESSAGE)
In my team I have noticed that the code example coming first often buries the text description of the error. I wonder if having the summary first would help new rescripters
I’ve just spent 15 minutes to realize what’s wrong, and it’s a component with 2 arguments. But I remember I’ve spent around an hour for a component with 15 arguments, had to delete it and start writing from scratch.
I think the one error that I face very often during refactoring is the “something somewhere” error, and while I understand what causes it now, there’s been more than a couple times I’ve had to go through and add explicit types all over the place to track down why something somewhere thinks this should be something else
Don’t know if it’s possible, but if the error message can include a small snippet of where the assumption is being made it would really help understanding why that’s happening
“dead” is a specific programming term, used often in the phrase “dead code analysis”, so I think it was probably used here in that context. Precision of language is quite important here because the compiler can’t know your future plans for a given piece of code.
I was looking for this feedback. I’m having a hardtime with this, so many times. This is not helping in my use case, I see “signature mismatch” and I end up comparing myself directly in the codebase.
Could color highlighting be a thing for specific parts of the signature mismatches?
I believe the error message itself is explicit enough (and with the whole signatures printed), it’s just painful to deal with.
This functor has type
(
T: {
module Query: {
module Raw: {
type t
}
type t
type t_variables
let query: string
let unsafe_fromJson: Js.Json.t => Raw.t
}
},
) => {
let call: (~variables: T.Query.t_variables) => Promise.t<
result<T.Query.Raw.t, string>,
>
}
The parameter cannot be eliminated in the result type.
Please bind the argument to a module identifier. ReScript
I’ve came across another confusing error message. I think adding quotes for the field name will make the error message readable, but maybe we can make something more.
