refactor: Don't restrict error type for Result<T, E>

[zharinov]

Changes

Error can not be right decision for representing error results: for example, we not necessarily want to have stacktraces.

There is no reason why error can't be of any type, including something lightweight like just true literal.

This PR refactors error type and also provides some improvements for the Result API.

Names has been aligned to zod schema library, as it solves very similar problems for us.

Context

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Could we not wrap anything in our own Error type?

[zharinov]

Could we not wrap anything in our own Error type?

Please, elaborate on that, I'm not sure I understand what you mean

[rarkins]

What's wrong with using Error for everything if we can extend it however we like?

[zharinov]

Here is the Rubygems-related code I'm refactoring at the moment:

export type VersionsResult = Result<
  string[],
  'unsupported-api' | 'package-not-found'
>;

I think for cases like this, Error class is too much:

• we have to declare couple classes separately
• in cases when Result is used just for control flow, we don't want stacktraces to be constructed, especially inside loops.

But when we need it, we still can have it I guess.

[zharinov]

Actually, maybe the single hierarchy of errors is the good thing, I just don't want them to be descendants of Error class. Hierarchy of nested union types (Error class included) looks good to me, though.

[renovate-release]

🎉 This PR is included in version 36.7.0 🎉

The release is available on:

• GitHub release
• 36.7.0

Your semantic-release bot 📦🚀