Error formatting helpers for deno_core embedders

[bajtos]

We are building a JavaScript/WASM runtime using deno_core and few other extensions. Thank you for providing these awesome building block to the community! ❤️

I would like to provide similar error reporting for our users as Deno CLI does.

I found a helpful function format_js_error, but it's implemented in deno_runtime crate and unavailable to deno_core consumers. It depends on fmt_errors module that's in deno_runtime again.

What I would love to have: a crate that provides the same error-reporting helpers as used by deno_runtime & Deno CLI and which can be used in projects embedding only deno_core.

I am happy to contribute such a change myself if you could give me guidance on what approach would be acceptable to you.

Questions coming to my mind:

• First of all, what do you think about this idea? Is it in line with your project vision and architecture?
• Should we move the code to deno_core or a new crate? I feel that error formatting with colours is beyond the scope of deno core and would add extra dependencies that many consumers may not want or like. On the other hand, maybe we can use Rust features to allow people to opt into these new error-formatting helpers.
• If it should go to a new crate - what name to give it and where to put it in the workspace?

[bartlomieju]

@bajtos is it a problem to depend on deno_runtime crate to use format_js_error API? Seems very specific to pull out this single API to a separate crate.

[bajtos]

Thank you @bartlomieju for your quick response!

is it a problem to depend on deno_runtime crate to use format_js_error API?

Adding the entire deno_runtime brings a ton of new dependencies into the projects, which increases build times. What's worse: I am not able to compile our project on GitHub Actions Windows runners, the build runs out of disk space.

My current workaround is to vendor fmt_errors.rs and colors.rs into our repository. 🤷🏻‍♂️

Seems very specific to pull out this single API to a separate crate.

I see your point.

As I was thinking about this topic more, how do you feel about pushing format_js_error down to deno_core? IIUC, few years ago, format_js_error was living in CLI and was then moved to deno_runtime. Moving it to deno_core seems like a natural next step on this path.

Maybe we should ask a higher level question. What is your vision for developer experience of embedding deno_core? In particular, how do you recommend to format JS errors for presenting them to end users?

The blog post Roll your own JavaScript runtime is very light on this topic, it uses the Display trait (IIUC):

    eprintln!("error: {}", error);

If the default display formatting was so good, then surely you would not need to implement format_js_error for Deno CLI, right?

[bartlomieju]

As I was thinking about this topic more, how do you feel about pushing format_js_error down to deno_core? IIUC, few years ago, format_js_error was living in CLI and was then moved to deno_runtime. Moving it to deno_core seems like a natural next step on this path.

Main reason I'm skeptical about the move is that fmt_colors.rs depends on the colors module, which in turn depends on termcolor and reading environmental variables - the idea for deno_core is to be as "pure" as possible in that it doesn't have surprising side effects. If we can find a reasonable way to not depend on reading env vars we can consider that.

Maybe we should ask a higher level question. What is your vision for developer experience of embedding deno_core? In particular, how do you recommend to format JS errors for presenting them to end users?

deno_core is bare-bones, it gives you building blocks for creating a runtime for your own needs, but most of the "fun" stuff in is deno_runtime.