[Feature request] bubble up underlying error as typed

[kwonoj]

Currently, the interface to compile mdx is like this

compile(value: &str, options: &Options) -> Result<String, String>

If the compilation fails, you'll only get a string error message, and you won't be able to access the actual error (Swc, etc.). With Turbopack, errors that occurred elsewhere can be controlled by a handler in the swc or some other way to show a separate message, which requires the actual error to be readable.

I'm curious if it's considerable to bubble up the actual error from compile, something similar to

compile(...) -> Result<String, CompileError>

CompileError {
  Ecma(E) // swc
  Hast(E) // hast
  Unknown(String) // other, not formed type
}

or could be some way like https://docs.rs/error-stack/latest/error_stack/#multiple-errors using libraries.

[ChristianMurphy]

This sounds related to https://github.com/wooorm/markdown-rs/issues/108, the discussion there is likely relevant here as well

[wooorm]

actual error

It is mostly unknown what “actual” is. While this project depends on SWC, most of the errors come from SWC through an arbitrary interface in markdown-rs, and then come up. So, markdown-rs first needs to support arbitrary errors?

There is also the case where there are, like, 30 different errors? And then the SWC/arbitrary ones? At that point, and also given the related issue Christian mentioned above, perhaps an error struct might be better (in JS we have https://github.com/vfile/vfile-message#fields). Which is something I would like, but haven’t made yet because it wasn’t needed before.

error-stack

markdown-rs is no_std + alloc, it’s intentionally minimal so others can build more on top. That isn’t needed in mdxjs-rs. But, we’d need to find something that works for both.