Make errors more meaningful (source mapping)

[Martinsos]

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.

[matijaSos]

I like the idea of injecting our own error handlers in the generated code. We could also have multiple versions of the generated code - e.g. one for development that has a lot of helpful stuff crammed in, then another for production and again another for "ejection", where we make it look as humane as possible.

[faassen]

I am not sure yet I understand the detail, but wouldn't browser source maps be of utility in this? It would only be of use for client-side errors directly, but perhaps we can use the same format for server side as well. It would be interesting to consider what (for instance) typescript does for NodeJS code and debuggers.

[Martinsos]

From what I know, source map is a way to map source to generated code when there is some kind of transpilation happening, and it is mostly useful to correctly place and describe errors.

So for example if Stylus is parsed into CSS, there will normally be a source map to describe which part of CSS relates to which part of Stylus.

Now, source maps might be browser, e.g. if running JS code that was generated from Typescript, but it could also be happening on the backend, e.g. node app that uses some language that transpiles in JS.

For Wasp, we would want it on both sides, both browser and backend/node/server. It would be up to us to generate source maps (from Wasp to generated code and from code in ext/ to code in the generated project), and then also to make sure they are used to transform the errors, to make them more meaningful.

I also don't have a good picture of details beyond this though.

[sodic]

This issue talks about source mapping and intercepting error messages to expand them.

Wasp has substantially changed since this issue's creation, and today we probably have better ways of dealing with all kinds of errors:

• Compile-time (TS) errors in user code are covered by #1718 and #2247.
• Code integration errors (errors that occur at connection spots between the framework and user code) are covered by #1664.
• Runtime errors are still problematic. The good news is that, since we no longer copy user code to the framework code and instead import it directly, improving these messages should be easier than the issue's description expects. The messages might even be acceptable already, we should check.