Runtime: Report error positions against a sourcemap

[josephjclark]

I don't think this will be easy, but it should be possible. And it's not tracked here, so:

When an expression throws, we should report an error against its sourcemapped source, refering to the line and column number, job name, and if appropriate the file name.

This is a bit tricky right now because errors are reported from the the VM inside SourceTextModule. I'm deliberately hiding stacktrace information because what we get for free is at best useless, at worst confusing.

The reported position has to refer back to the uncompiled code - although this may give us a problem if the error is in the compiled stuff (like import {fn }).

[stuartc]

Check out magic-string as a potential tool for generating source maps iteratively https://www.npmjs.com/package/magic-string

[doc-han]

I'm having some silly idea of generating an inline source map after the compiler transformation and adding that to the final code that's going to be executed by the vm(mostly).

I currently don't know whether the inline source map will be considered when an error is thrown

It seems the major difference between source code and compiled code is some additional code that wraps it. Hence we should be able to map the lines I guess. eg. source

fn(state=> state)
fn(state=> {
  state.data.smth = "smth"
  return state;
})

eg. compiled

import {fn} from "@openfn/common"

export default [
fn(state=> state),
fn(state=> {
  state.data.smth = "smth"
  return state;
})
]

mostly the entire source code just sits in the array.

Just some random thought.

[josephjclark]

Hi @doc-han - I'm actually half way through this story. We get a source mapping solution out-of-the-box with recast - it's just about applying it in the right places in the code.

I've got a prioritised work list for you with plenty of interesting compiler and runtime stuff, and we've got a couple of bigger projects planned too. Hang tight and we'll keep you busy!