How to get better error reporting with typst.ts?

[justpankajdotcom]

Hi,

I am constantly using this amazing library and it has been great, thanks for maintaining it. I have a question with the error reporting part of it. I was using another product around - typst-preview, I think to which you are also a maintainer. I tried compiling some of my documents in it, and it very efficiently directs to the line the error happening, along with the line number, for example -

(line)39 error: expected expression

When I tried compiling a document with my typst.ts setup, it reported error efficiently, but I think there are some more processing required to direct to the line number, for example, catch the error and print it to the console, it looks like this

[SourceDiagnostic { severity: Error, span: Span(143747411669795), message: "the character # is not valid in code", trace: [], hints: [] }]

If my understanding is correct, Span(xyz) does exactly that. Is it possible to translate this to point to the line number the error is happening? If it is something that needs to be done on my part, can you guide me where I can look it up?

[Myriad-Dreamin]

Sorry about late, I was on vacation.

My understanding is correct, Span(xyz) does exactly that.

You are correct, we currently have full information about diagnostics. But typst.ts still doesn't provide a way to access that information. It needs carefully design.

For design of processing diagnostics, there are three different directions.

1. typst-preview uses rust API of typst.ts, so there is no problem for exporting diagnostics information. typst-preview can use the typst crate's SourceDiagnostics directly, and it can convert Span inside of SourceDiagnostics by World api easily.

2. I experiment a bit on typst.node for API design of js binding, it can raise an error that stores raw spans, and convert them later. I'm satisfying with that API.

3. We can go API design for typst.ts like what we have done on typst.node. However, there is a problem: if we store raw information inside of the error, then the error needs free, which would be hard to use. This is because node.js will automatically frees napi objects but wasm-bindgen never does that!!! I keep thinking of that for months but I don't get good idea yet. It means that you will always have to compile document with following code (so I don't do that):

try {
  const doc = compile("");
} catch(e) {
  // process error here with `e` that stores information from rust.
  void(e.span);
  
  if (e.free) { // otherwise we will get memory leak...
    e.free();
  }
}

[justpankajdotcom]

Thank you, I really appreciate your reply and explanation.

[Myriad-Dreamin]

I have created an issue for tracking design of diag API, #486.