tests in TypeScript (.ts files) lack stack traces

[erights]

See Agoric/agoric-sdk#8662

From Agoric/agoric-sdk#9700

file://test/facade.test.ts:1:1043

vs

(test/facade.test.ts:52:9)

Why are we seeing this difference? Clearly, the second stack trace is more informative, and the tamed stack trace from Endo, whether 'safe' or 'unsafe', should show this more informative one. It looks like the second is relative to the source code the programmer wrote, which is ideal. But of course, the source is TS and what's executing is the JS that the TS compiles to. From the first, I'd guess that either the TS compiler is compiling into a single line of JS, or that some bundler is flattening the compiled JS into a single line of JS. But in either case, we should understand why the second stack trace is more informative. Is it based on a source map generated by the TS compiler? How does the native v8 stack get to be adjusted for that, but not the stack we're forming using the JS error API internally?

[mhofman]

I'd guess that either the TS compiler is compiling into a single line of JS

Correct

we should understand why the second stack trace is more informative. Is it based on a source map generated by the TS compiler? How does the native v8 stack get to be adjusted for that, but not the stack we're forming using the JS error API internally?

TS does generate source maps. And Node.js uses prepareStackTrace to parse source maps and recreate the authored stack trace info. v8 itself doesn't know anything about source maps. However when SES overrides prepareStackTrace, we lose that Node.js behavior aware of source maps. Since we can't invoke that original behavior because of strange layering inside Node.js, we're left with having to re-implement the source mapping behavior ourselves in SES. See #1798