fix: error stack traces in transpiled TypeScript

[bajtos]

This is a follow-up for #717, where we added TypeScript transpilation but did not test how it works in practice.

The implementation is based on this Deno example:
https://github.com/denoland/deno_core/blob/0.343.0/core/examples/ts_module_loader.rs

Example code:

interface User {
  name: string;
  email: string;
}

const err: Error = new Error("boom!"); throw err;

Deno output:

error: Uncaught (in promise) Error: boom!
const err: Error = new Error("boom!"); throw err;
                   ^
    at file:///project/x.ts:6:20

Zinnia before this change - notice the missing : Error snippet and wrong source code line & column numbers:

error: Uncaught (in promise) Error: boom!
const err = new Error("boom!");
            ^
    at file:///project/x.ts:1:13

Zinnia after this change (same output as from Deno):

error: Uncaught (in promise) Error: boom!
const err: Error = new Error("boom!"); throw err;
                   ^
    at file:///project/x.ts:6:20

Links:

• Upgrade Deno & Rust toolchain to latest #676
• Better Developer Experience for Module Builders #30

Related:

• Consume source maps from JavaScript files denoland/deno#4499
• [WIP] feat: Add native SourceMap support denoland/deno_core#819

[bajtos]

In retrospect, it was a mistake to use Option<AnyError> here. I would like to rework this to return Result<(), AnyError> instead, but such refactoring is out of scope of this pull request.

@NikolasHaimerl, do you have a suggestion on how to best represent a type with the following variants in Rust?

• We cannot execute the JS/TS file -> Err(AnyError)
• We executed the JS/TS file and collected some logs in Vec<String>. In addition to these logs, we want to provide:
  • The script executed cleanly -> ()
  • The script threw a runtime error -> AnyError

Variants:

1. Err(AnyError)
2. Ok((Ok(()), Vec<String>))
3. Ok((Err(AnyError), Vec<String>))

[NikolasHaimerl]

How about we wrap the logs inside the Anyhow context string?

[bajtos]

I see what you mean. We need to extract the logs from the results, so that we can assert what exactly was logged by the test runner on failure. Do you know how to extract one piece of a context from the Anyhow error?

[bajtos]

I am leaning towards using Result<(Result<(), AnyError>, Vec<String>), AnyError>.
I.e. Result<ScriptResult, AnyError> where ScriptResult is a tuple (Result<(), AnyError>, Vec<String>).

[bajtos]

Would it help to create a named struct ScriptResult?

Alternatively, maybe we can treat the case "we cannot execute the script" the same way as "the script threw an error".

That will give us (Result<(), AnyError>, Vec<String>)

• We cannot execute the JS/TS file -> (Err(AnyError), vec![])
• The script executed cleanly -> (Ok(()), logs)
• The script threw an error -> (Err(AnyError), logs)

WDYT?

I'd also like to make this refactoring as a follow-up, after I land the remaining two pull requests.

[NikolasHaimerl]

I see what you mean. Ideally I would like to avoid having a result inside a result. We could use enums as error types to give us specific information about which error was caused by the test runner. Why do we not unwrap an error once it occurs? What is the benefit of propagating it upwards if it is only used in testing?
Usually, in Rust testing, I would expect Errors to be unwrapped as they occur within the testing suite. Error propagation, I would usually only do in production.

[bajtos]

Makes sense.

Why do we not unwrap an error once it occurs?

In some tests, we want to assert that execution of the JS code threw an error and that the JS code produced the expected logs.

What is the benefit of propagating it upwards if it is only used in testing?
Usually, in Rust testing, I would expect Errors to be unwrapped as they occur within the testing suite. Error propagation, I would usually only do in production.

I find it easier when all test helpers use error propagation instead of unwrapping, because that way I don't have to decide in each test helper which error-handling strategy is appropriate.

Let's continue this discussion in #752

[bajtos]

This is similar to the code we have in format_test_activities() below, but not exactly the same. WDYT, is it worth extracting a shared helper function?

zinnia/runtime/tests/runtime_integration_tests.rs

Lines 153 to 189 in 8680101

	fn format_test_activities(events: &[String]) -> String {
	// Find all durations (e.g. `0ms` or `241ms`)
	let duration_regex = regex::Regex::new(r"\d+ms").unwrap();
	// Find trailing whitespace on all lines. Note that a chunk can be multi-line!
	let eol_regex = regex::Regex::new(r" *\r?\n").unwrap();
	let cwd_url = ModuleSpecifier::from_file_path(std::env::current_dir().unwrap()).unwrap();
	events
	.iter()
	.map(|chunk| {
	// Strip ANSI codes (colors, styles)
	let chunk = console_static_text::ansi::strip_ansi_codes(chunk);
	// Remove `console.info: ` added by RecordingReporter.
	// Don't remove other `console` level prefixes, so that we can detect them.
	let chunk = match chunk.strip_prefix("console.info: ") {
	Some(remainder) => remainder,
	None => &chunk,
	};
	// Replace current working directory in stack trace file paths with a fixed placeholder
	let chunk = chunk.replace(cwd_url.as_str(), "file:///project-root");
	// Normalize durations
	let chunk = duration_regex.replace_all(&chunk, "XXms");
	// Remove trailing whitespace before all EOLs
	let chunk = eol_regex.replace_all(&chunk, "\n");
	// Format the line, adding back EOL after trimming whitespace at the end
	format!("{}\n", chunk.trim_end())
	})
	.collect::<Vec<String>>()
	.join("")
	}

[NikolasHaimerl]

Is the module loader exclusively single threaded?

[bajtos]

Great question! I am not sure, TBH.

We are running the Deno runtime on the current thread, see here:

zinnia/daemon/main.rs

Line 21 in 2d40376

#[tokio::main(flavor = "current_thread")]

zinnia/cli/main.rs

Line 17 in 2d40376

#[tokio::main(flavor = "current_thread")]

I think that means all async tasks will be executed on the current thread too, including the asynchronous work of the module loader.

Deno uses Rc<RefCell<...>> in their example:

https://github.com/denoland/deno_core/blob/0.343.0/core/examples/ts_module_loader.rs

My knowledge of async Rust is very limited, I don't understand this deeply enough. What would you suggest to use?

[NikolasHaimerl]

Ah I see, well Rc<RefCell<...>> is used in a single-threaded environment, since Deno is using that as an example, I would assume it is single threaded. If we were to use multithreaded environments, I'd rather go for a Arc<Mutex<...>> type.

[NikolasHaimerl]

Approving, as the result structure can be improved in a follow up PR