[FEATURE] Can't see cause or aggregate details for uncaught errors about tapjs HOT 13 OPEN

I'm noting that this is probably related to tapjs/stack-utils#61, which has a whole ton of discussion about cause formatting in general. It's probably the place to go to discuss specifics on that mark! (See also jestjs/jest#11935.) But I'm keeping this issue around as tracking for other ways to integrate custom or Node.js-built-in error tracing for tap itself.

from tapjs.

I've done some digging in the source to try to get more familiar with basically how tap works and where changes would be needed, and the give-away (after digging in the reporter code) is that the reporter is most certainly parsing the tap results, with no extra "magic" after the fact to generate new information, so the core test runner is responsible (which generates tap output) is responsible for stack tracing.

Specifically, the function we've gotta look at is TestBase.threw. Stack tracing is handled here, essentially joining (one for each line) the results of parseStack. Internal details are super interesting (@tapjs/stack is cool!) but not relevant for this issue, since they're lower level than processing a thrown error object itself.

I'm not sure what the ideal solution would be for embedding information that isn't a plain stack trace into the results here. I guess the good thing is that YAML Diagnostic blocks aren't standardized? So we can choose to add completely new information here, without altering the existing expected contents of stack.

Personally, seeing as it's a structured YAML object anyway, I think we should basically allow recursive details here, exactly the same as the current flat shape is reported, just without tapCaught (since I'm assuming that's only relevant to the top-level error). That means including stack, at, and source for every nested error, as well as cause (single item recursive) and errors (array recursive) when applicable. (Oh, and message for nested errors, too!) It'd be up to the reporter to decide what to do with that data — including not displaying it at all, for example.

Of course, all this means that as-is, cause and errors information is just completely discarded — it's not part of the TAP output (i.e. YAML diagnostic block) and so unavailable for processing by reporters.

tap's error reporting for result details is handled by ResultDetails, and expressly parses the diagnostic object to provide source and stack information (respectively Source and Stack). If we add a new key on the diagnostic results - rather than messing with the existing stack - then we'd need to add a new element for handling recursion, displaying message and at information for sure, and maybe a compressed/context-sensitive version of stack (ala Node.js) and maaaaaaybe source if an option is set, too.

Actually, if stack is context-sensitive, we need the top-level stack to be similarly context-sensitive. We could accomplish that in two ways:

1. By providing the entire diagnostic structure to Stack and a pointer to the current entry in that structure, allowing Stack to infer which lines are duplicates and should be hidden for conciseness
2. By doing that processing ourselves and just providing a concise stack string to Stack from the get-go, and making the recursive component responsible not just for nested stacks, but the top-level one too (since it'll contain the conciseness logic)

I'm definitely inclined more towards the second approach, because it keeps Stack logic simple, isolates recursive or recursion-sensitive logic into a dedicated component, and avoids "special" behavior for trace reporting on the top-level error, since that's just a case where the root node is also the (only) leaf node.

I might give implementing all of this a shot, since implementation-wise it doesn't sound dreadfully complicated (recursion in TypeScript isn't that hard, right!?), and would be a fun project to get familiar with tap's internals — even if any of this is out of scope for tap or some totally different approach is selected. But no guarantees I'll get anywhere with my code! 👾

from tapjs.

We did it!

We still need to do test cases, and probably some extra-detail adjustments (it doesn't display the error type, nor any otherDiags-style details; stack beneath heading should possibly also be indented to match Node.js...) — but the essential implementation is all here. See our detailed commit messages if so desired. (We'll try to make a PR happen sometime soon.)

Also some checking against Node.js to make sure everything is, in fact, working precisely as intended (that's where we're pulling the essential appearance, "42 lines matching cause trace" messaging, and a chunk of implementation code from).

from tapjs.