Emulation of Rusts `?` Result operator (implicit return for errors)

neverthrow now can support implicit return whenever there is an Err instance inside of a generator.

Context: #448

Thank you to @tsuburin for the contribution 🚀

---

Additionally, the previous functionality around increasing the tuple size supported by neverthrow is now live and out of beta. Context: https://github.com/supermacro/neverthrow/releases/tag/v6.0.1-0

Release Candidate: Allow for type inference of tuples containing 49 or less elements

I am a simple man - I like my tuples like my coffee; small (but strong). But some of you are out here trying to wreak havoc on the world with very large tuples. Now you get type inference on these too 🙂

---

This is a fix for #441

The fix allows for type inference on very large tuples (limit of 49).

Given the sensitive nature of the changes made at the type level, I've opted to release this incrementally and as an opt-in functionality for now.

To get this change, you'll need to update your neverthrow installation to use the @beta tag.

> npm install neverthrow@beta

I'll wait a bit before moving this over to default on npm.

Resolve accidental breaking change with type inference on array types

The combine* family of functions (both sync and async) broke any codebase that called these functions on arrays of varying lengths when the previous release was shipped:

https://github.com/supermacro/neverthrow/releases/tag/v5.1.0

The following fix was implemented to address this issue and ensure that arrays (not just tuples) work with the combine* family of functions.

#435

Why is this shipped as a MAJOR version change?

Because we are now explicitly depending on TypeScript's variadic tuple types feature, which came out in v4 of TypeScript:

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#variadic-tuple-types

Acknowledgements

Thank you to @ghost91- for implementing the fix 🙏

Type inference improvements for all of the "combine" functions!

Thanks to @incetarik for fixing a long-lasting developer inconvenience! #226

Now, all of the "combine" functions can now infer types correctly and treat the list argument as a tuple rather than an unbounded list!

i.e. Rather than having to do:

Result.combine([ ok(123), err('whopps!') ] as const)

You can just omit the as const now:

Result.combine([ ok(123), err('whopps!') ])

And neverthrow can figure out the type of the above tuple on its own!

Return `never` rather than `unknown` for error type of `ResultAsync.fromSafePromise`

Thank you to @ccjmne @lmcsu and @msheakoski for this improvement 🙏

This release ships #425 - which ensures that the E type for ResultAsync.fromSafePromise is never by default - which makes a lot more sense / is more a "accurate" depiction of runtime behaviour.

Separate `combine` and `combineWithAllErrors` into sync & async APIs

Thank you to @tam-carre for implementing this fix!

Unfortunately there is no way to distinguish at runtime if an empty list is a list of ResultAsyncs or a list of Results.

Hence #381 ... which could cause runtime exceptions!

So we've had to make the unfortunate decision of splitting combine and combineWithAllErrors into a synchronous version (behind the Result namespace) and an asynchronous version (behind the ResultAsync namespace).

So now we have:

• Result.combine
• Result.combineWithAllErrors
• ResultAsync.combine
• ResultAsync.combineWithAllErrors

... of course, this is a breaking change, and as such neverthrow has now been bumped to version 5.0.0

Make `ResultAsync.fromPromise` and `ResultAsync.fromSafePromise` less strict!

Thanks to @bhvngt for this submission.

ResultAsync.fromPromise and ResultAsync.fromSafePromise are now able to accept anything that implements the PromiseLike interface - in other words; anything that is "thenable". This includes objects such as Bluebird Promises and any other non-native promise-like object!

Fix issue when calling `combine` on proxies

User kieran-osgood submitted a fix for a long standing issue whereby proxies were suddenly disappearing within calls to combine:

#228

This issue is now resolved!

Additionally, the docs have been updated to reference eslint-plugin-neverthrow.

Type Inference Improvements on `andThen` + `orElse`, and more flexible `unwrapOr` method

Many thanks to @sidhu663 for these great improvements to neverthrow.

Significantly Improved Type Inference On andThen and orElse Methods

With this release, you should not need to explicitly annotate the return type on the callbacks called into andThen and orElse.

Example:

Before

const slotsResult = ok(123).andThen((value) =>
  value === '777'
    ? ok('Lucky Sevens')
    : err('Try Again')
)

Before, slotsResult would be of type Result<unknown, unknown>.

The "solution" was to explicitly annotate your callback function as returning Result<string, string>

After

This exact piece of code above now types slotsResult as Result<string, string>!

If you're interested in how this works, check out the PR that implements these improvements here: #349

Additional notes

• This same improvement applies to .orElse
• These improvements are for both Result and ResultAsync

More Flexible unwrapOr Method

The type signature of .unwrapOr has been "widened" to allow for returning something other than a type T as defined by the Result / ResultAsync you are calling unwrapOr on.

This change was implemented in #350.

Example:

const result = err<number, string>('boom').unwrapOr(false)

The above did not work prior to v4.3.0 because boolean (the false value) is not of type number.

But now you are not constrained by this! As of v4.3.0 you now have the ability to specify a value of any type within unwrapOr.

In the above example, result is now of type number | boolean.

Make fromThrowable accept functions with varying degrees of arity

Fixes #300

This PR updates the type definition of Result.fromThrowable in order to allow accepting functions that take 1 - n arguments.

Thanks to @universalhandle for the contribution 👏