3.2.0

Minor Changes

Result.fromAsync now also takes a callback function

Instead of only accepting a promise, you can use a callback function to create an AsyncResult instance:

function getUser(userId: string) {
  return Result.fromAsync(async () => {
    const user = await fetchUser(userId);
    
    if (!user) {
      return Result.error(new NotFoundError());
    }
    
    return Result.ok(user);
  });
}

This functionality is mainly a replacement for having to wrap the return of a function call in Result.fromAsync first, before being able to do any chaining. By using the callback variant of Result.fromAsync, the responsibility of transforming the async operation into an AsyncResult shifts from the consuming code to the source. Either way is fine, so it's mainly a matter of preference.

Result.recoverCatching and AsyncResult.recoverCatching now both have an optional transformError callback

Similar to what Result.mapCatching and AsyncResult.mapCatching already had, you can now transform any caught exceptions into a custom error:

declare const failedResult: Result<number, SomeError>;

const nextResult = failedResult.recoverCatching(
  () => {
      // logic skipped for brevity
      
      throw new Error("Boom")
  },
  (error) => new CustomError("Failed to recover", { cause: error }
);

Various improvements of types

Most notable are complex union types that now get merged into a single Result or AsyncResult:

type Before = Result<number, never> | Result<never, SomeError> | Result<number, SomeOtherError>

type After = Result<number, SomeError | SomeOtherError>;

3.3.0-beta.1

v3.3.0-beta.1

initial generator functionality

3.2.0-beta.6

v3.2.0-beta.6

adds optional transform-error callback to recoverCatching to transfor…

3.1.1

Fixes

• Fixes cases where exceptions thrown inside AsyncResult's were trapped, which resulted in unhandled exceptions.

3.1.0

Minor changes

• adds toTuple() to both the Result and AsyncResult class, allowing you to destructure a result and use TypeScript's narrowing capabilities (instead of having to check with isOk() and isError()).

declare const result: Result<number, ErrorA>;

const [value, error] = result.toTuple();

if (error) {
  // error is ErrorA
} else {
  // at this point the value must be a number
}

// or 'Go-style'
if (error === null) {
 // do something with the value
}

3.0.0

Breaking changes

• #2 Throws the error directly instead of wrapping the encapsulated error in an additional error when using getOrThrow()

2.1.1

Fixes

• Fixes issue where AsyncResult's onSuccess and onFailure did not await promises well, resulting in 'dangling' promises

2.1.0

Minor changes

• added mapError method to both the Result and AsyncResult instances, which allows you to transform the encapsulated error of a failed result (#9 )
• added an additional parameter to the mapCatching method (transformErrorFn) which allows you to transform the potential error caught while transforming. (#9)

Thanks @derkbell for suggesting this improvement and helping out with a solution!

Fixes

• Moves the default export condition to last position in package.json. See #6.

Thanks @trombipeti for helping and pointing this out!

2.0.0

v2.0.0

bumps version

2.0.0-beta.1

v2.0.0-beta.1

adds release workflow