feat: support native Error causes

[legobeat]

Alternative/follow-up to #140.

This utilizes the runtime Error constructor parameter options.cause to propagate data.cause. The explicit assignment of the property in #140 is preserved as fallback, which should make this change non-breaking.

This requires change tsconfig lib from ES2020 to ES2022 to be recognized. Alternatively, if allowing es2022 lib is not desired at this point, the cause prop could be explicitly added/shadowed like in #140.

Related

• Property 'cause' does not exist on type 'Json & ExactOptionalGuard' #129
• Allow passing a cause to predefined error functions #83
• Allow passing unknown values as cause #91
• types: Make Data type-parameter optional in JsonRpcError #102

Based on

• feat: propagate data.cause as cause in JsonRpcError constructor #140
• chore(tsconfig): bump lib from es2020 to es2022 #142

metamask-extension preview branch

• fix(deps): update from eth-rpc-errors to @metamask/rpc-errors (cause edition) metamask-extension#24496

[legobeat]

The reductions here arise from the fallback never triggering since native causes are not used in all tested environments.

Adding test-coverage for the fallback would involve some wider changes to the test suite, I believe.

[Mrtenz]

I think this makes sense. When serialised, the cause is still serialised as data.cause, right?

[legobeat]

I think this makes sense. When serialised, the cause is still serialised as data.cause, right?

That's the idea, yes!

[rekmarks]

LGTM.

[mcmire]

Hmm, I'm not sure we can do this yet due to React Native not supporting ES2020+. There is a thread in chat about this. Search for "ES2020"; it should be the third message down. (I'll DM it to you.)

These changes look good to me otherwise, though.

[legobeat]

@mcmire Since es2022 is not an option, which of the following is preferred?

• Adding dom instead
• Defining/shadowing the cause property explicitly

[legobeat]

Closing in favor of #140