fix: harden error handling in lib/cli/run.js

[stalet]

Before this patch the errorhandling would fail with the error: "ERROR: null". Debug showed that the error "caught error sometime before command handler: TypeError: Cannot convert object to primitive value"

PR Checklist

• Addresses an existing open issue: fixes 🐛 Bug: Errorhandling fails when node:module registered errors are thrown #5085
• That issue was marked as status: accepting prs
• Steps in CONTRIBUTING.md were taken

Overview

When the error in the runner is a typescript error the current script fails with the error: "TypeError: Cannot convert object to primitive value" - leaving the output as a null value.
It is very hard to see the actuall error. With this change the output will be something like this.

Error: undefined test/testdata.ts(59,14): error TS2739: Type '{ loginId: number; spidId: number; sid: string; amr: never[]; }' is missing the following properties from type 'Identity': sub, nbf, exp, iat

Before the fix the output was
✖ ERROR: null
Debug output contailed this
mocha:cli:cli caught error sometime before command handler: TypeError: Cannot convert object to primitive value mocha:cli:cli at exports.handler (/home/stalet/code/account/min-finn-frontend/node_modules/.pnpm/[email protected]/node_modules/mocha/lib/cli/run.js:372:65) +859ms

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: stalet / name: Ståle Tomten (77934c1, 25bda25, d5105f0, 8b7613c, 8a07c4f, d9e64ad, cc1c7ad, b70a40c, 3a11def, 8be4ad1, 5b398f7)
• ✅ login: voxpelli / name: Pelle Wessman (9a65149, f66505f, b264a59)

[voxpelli]

Can you provide a reproduction? Sounds odd that it would swallow all TypeScript errors currently

Other PR:s related to error reporting are eg:

• feat: include .cause stacks in the error stack traces #4829
• feat: support reporting AggregateErrors  #5018

[stalet]

I have created a small project that reproduces the error here: https://github.com/stalet/mocha-typescript-testproject

[barak007]

It's a general thing with errors not related to Typescript

console.error('\n' + (err.stack || `Error: ${err.message || err}`));

the above line from mocha fail if I throw null as an error

try {
 throw null;
} catch (err) { 
  console.error('\n' + (err.stack || `Error: ${err.message || err}`));
}

the error will be

Uncaught TypeError: Cannot read properties of null (reading 'stack')

[JoshuaKGoldberg]

👀

• Addresses an existing open issue: fixes #000

See .github/CONTRIBUTING.md. We ask that PRs address an open accepted issue first. A few benefits:

• Issues are much more discoverable for folks looking to discuss & report suggested changes.
• The issue templates ask for the info needed to properly triage the suggestion.
• We don't want unhappy situations where someone spends their time on a PR that can't be accepted (which would have been caught by an issue's discussion).

Closing this PR so it doesn't show up on our review queue. But if it is determined in an issue that we can take this in, we'd be happy to re-open and review. Thanks for sending!

tl;dr: please file an issue so we can discuss there 🙂.

[coveralls]

coverage: 94.312% (-0.02%) from 94.335%
when pulling 8be4ad1 on stalet:bugfix-typescript-errors-not-outputted
into 3345eff on mochajs:master.

[JoshuaKGoldberg]

Requesting changes to handle the node:module case of errors that don't have a toString() method. Please let me know if I've gone down the totally wrong track though!

[stalet]

After these changes I have verified the in the testproject i get the following output instead of ✖ ERROR: null

Undefined error: test/index.test.ts(9,44): error TS2322: Type 'string' is not assignable to type 'number'.

Which was the intention.

[barak007]

LGTM.

now we only need to support AggregateError and Error cause and it will be perfect reporting
I think they have separated issues

[voxpelli]

Yep, and I think they are all waiting on me, I'll try to squeeze them all in this Monday:

• feat: support reporting AggregateErrors  #5018
• feat: include .cause stacks in the error stack traces #4829