wasp icon indicating copy to clipboard operation
wasp copied to clipboard

Make errors more meaningful (source mapping)

Open Martinsos opened this issue 5 years ago • 4 comments

Right now, errors are coming directly from client/server, and often it is not easy to connect them with the Wasp source code, since generated code should be opaque to the user, but in this sense it is not.

We need to find a way to give errors more meaning, connect them to the Wasp code (both .wasp and ext/ code). This will not be an easy task, since it is questionable how much control we have over them, how can we intercept them and how much do we understand what they are about.

To do this, we need to somehow intercept errors and then attach more information to them. We can choose to display both new, attached information and old information, or just new information.

How can we intercept them? One way would be to intercept them on stdout of client and server processes. This does not seem great, since we depend a lot on how they are being outputed, formatted, and so on, there is a lot of text processing here that does not conform to any strict standard and could easily be broken. Another way, better way, would be intercept them programmatically, where we have more control and hopefully there are more conventions as to how they are organized and formatted. We could inject top-lvl error handlers in generated code that would do this transformation. Or, we could monkey-patch them into the generated code. There are still certain errors we will not be able to catch this way, like errors coming from tools like standardjs -> basically static analysis tools / linters.

Ho do we transform/enrich errors? We should probably use some kind of source mapping, so if error happens at certain place in generated code, we can connect it to the source code. I am not sure what will this take, but it should be possible. I think finding a solution that will 100% catch all errors in a uniform way will not be possible. Instead, it probably makes most sense to focus on most prominent / easiest to tackle errors, and then we build from there, expanding the solution to capture more and more errors as we encounter them, organically.

Obviously I merely scratched the surface of the problem, so more though is required here for sure, and hopefully we might even come up with smarter approach. We should also research how others are doing this.

Martinsos avatar Oct 13 '20 13:10 Martinsos