I just spent the last few days chasing my tail on this one. I was using several mocking libraries, notably ts-mockito and testdouble, and got the same behavior. If I created a mock object, wrapped it with okAsync(), and tossed that into combine(), I would get nothing in the return- the mock object was being dropped. Here's an example test in jest that would fail:

import td from "testdouble";

interface ITestInterface {
    getName(): string;
    setName(name: string): void;
    getAsyncResult(): ResultAsync<ITestInterface, Error>;
}

describe("Debugging and basic info tests", () => {
test("combine works with TestDouble mocks of interfaces", async () => {
    // Arrange
    const mock = td.object<ITestInterface>();

    // Act
    const result = await combine([okAsync(mock)]);

    // Assert
    expect(result).toBeDefined();
    expect(result.isErr()).toBeFalsy();
    const unwrappedResult = result._unsafeUnwrap();
    expect(unwrappedResult.length).toBe(1);
    expect(unwrappedResult[0]).toBe(mock);
  });
});

If you run this, you'd find that the last two expect calls would fail, because combine would return an empty array! It would only do this with mocks, not with normal objects. So I dug into it, and I found a solution in the combine() code. You are using array.concat(nonArray) in the reduce() of combineResults(). I rolled my own combine and it works even with mocks. I added typing support for heterogenous lists as well, but it looks like you're working on a slicker solution in another issue. Here's my "fixed" combine:

export class ResultUtils {
    static combine<T, T2, T3, T4, E, E2, E3, E4>(asyncResultList: [ResultAsync<T, E>, ResultAsync<T2, E2>, ResultAsync<T3, E3>, ResultAsync<T4, E4>]): ResultAsync<[T, T2, T3, T4], E | E2 | E3 | E4>;
    static combine<T, T2, T3, E, E2, E3>(asyncResultList: [ResultAsync<T, E>, ResultAsync<T2, E2>, ResultAsync<T3, E3>]): ResultAsync<[T, T2, T3], E | E2 | E3>;
    static combine<T, T2, E, E2>(asyncResultList: [ResultAsync<T, E>, ResultAsync<T2, E2>]): ResultAsync<[T, T2], E | E2>;
    static combine<T, E>(asyncResultList: ResultAsync<T, E>[]): ResultAsync<T[],E> {
        return ResultAsync.fromPromise(Promise.all(asyncResultList), 
        (e) => {return e as E})
        .andThen(ResultUtils.combineResultList);
    }
    
    static combineResultList<T, E>(resultList: Result<T, E>[]): Result<T[], E> {
        return resultList.reduce((acc: Result<T[], E>, result) => {
            return acc.isOk()
                ? result.isErr()
                    ? err(result.error)
                    : acc.map((values) => {
                        values.push(result.value);
                        return values;
                    })
                : acc;
        }, ok([]));
    };
}

While reading through the docs of Rust's Result type, I learned that they annotate Result with a compiler attribute that enforces a user to "do something" with the result.

It might be nice to introduce an eslint rule that does this for neverthrow.

It would prevent situations like this:

const doSomethingThatMayFail = async () => {
  await changeUserPassword() // Returns a `Result<null, DbError>`
}

Note that we haven't checked to see if changeUserPassword actually succeeded.

Edit:

Learning Resources:

• https://dev.to/spukas/how-to-write-your-first-eslint-plugin-145
• https://dev.to/alexgomesdev/writing-custom-typescript-eslint-rules-how-i-learned-to-love-the-ast-15pn

Hi,

Thank you for publishing this!

I wanted to get started right away but ran into a seemingly trivial problem I am too much of a noob to solve. Any help would be appreciated!

The compiler complains when I want to compose multiple results with the .andThen() method

type E1 = 'invalid'
type E2 = 'also invalid'
type E3 = 'invalid again'
type Errors = E1 | E2 | E3

const f1 = (sth: unknown) => Result<string, E1>
const f2 = (input: string) => Result<string, E2>
const f3 = (thing: string) => Result<string, E3>

const result: Result<string, Errors> = f1('test')
                         .andThen(f2)
                         .andThen(f3)

The compiler complains that that the result of f1 is not assignable to the result of f2, specifically Result<string, E1> is not assignable to Result<string, E2>.

I thought that the mismatch of results and function parameters wouldn’t hurt, because .andThen() doesn’t even call the next function if the result is of type Err. Any idea how I could help with the type inference?

Hi. With my understanding, only typing stops combine currently from working with heterogeneous Results, implementation looks ready for them. I just prepared types for combine that works for Result of many types, at least in my tests. Could it be useful for the library?

It will only works for TS 4.0+.

declare function combine<T extends Result<unknown, unknown>[]>(
    resultList: [...T]
  ): CombineResult<T, T>;


type CombineResult<T extends unknown[], U extends unknown[]> = T extends [
  infer Element,
  ...(infer Rest)
]
  ? Element extends Err<unknown, infer ErrH>
    ? Element
    : CombineResult<Rest, U>
  : Ok<
      { [Index in keyof U]: U[Index] extends Ok<infer OkElement, unknown> ? OkElement : never },
      unknown
    >;

This is next proposition to solve problem with #224.

I feel I learned a lot about TypeScript in last week ;) Today I tried again to provide proper types for Heterogeneous combine function.

First, I would like to provide my new proposition, implementation of combine types, based on our findings in #224 and my experimetns.

import { Result, Ok, Err } from 'neverthrow';

declare function combine<T extends readonly Result<unknown, unknown>[]>(
  results: [...T]
): Result<ExtractOkTypes<T>, ExtractErrTypes<T>[number]>;

// Given a list of Results, this extracts all the different `T` types from that list
type ExtractOkTypes<T extends readonly Result<unknown, unknown>[]> = {
  [Key in keyof T]: T[Key] extends Result<unknown, unknown>
    ? ExtractOkFromUnion<T[Key]>
    : never;
};

// Given a list of Results, this extracts all the different `E` types from that list
type ExtractErrTypes<T extends readonly Result<unknown, unknown>[]> = {
  [Key in keyof T]: T[Key] extends Result<unknown, unknown>
    ? ExtractErrFromUnion<T[Key]>
    : never;
};

// need to be separated generic type to run it for every element of union T separately
type ExtractOkFromUnion<T extends Result<unknown, unknown>> = T extends Ok<
  infer V,
  unknown
> // filter out "unknown" values
  ? V extends {}
    ? V
    : never
  : never;

// need to be separated generic type to run it for every element of union T separately
type ExtractErrFromUnion<T extends Result<unknown, unknown>> = T extends Err<
  unknown,
  infer E
> // filter out "unknown" values
  ? E extends {}
    ? E
    : never
  : never;

I'm using Jest as a test framework. My naive attempts at writing tests for functions that return a Result typically look like:

expect(callSomeFunction("with", "some", "args")).isOk()).toEqual(true);
expect(callSomeFunction("with", "some", "args"))._unsafeUnwrap()).toEqual(someExpectation);

This is a bit clumsy because:

• I need to double all test calls just for the isOk() and _unsafeUnwrap() parts. Especially if the callSomeFunction("with", "some", "args") expression is long, this causes quite some overhead.
• When the function fails, the runner only outputs that isOk() wasn't true. Any helpful information in the error object remains hidden. I frequently copy paste the expression into a third line for an ad-hoc console.log just to get some information, which of course feels wrong ;).
• Using _unsafeUnwrap and _unsafeUnwrapErr basically everywhere looks a bit ugly and feels like an anti-pattern.

I'm be no means a Jest expert and still have to check if it offers something that could help here.

I just wanted to bring up the topic, perhaps there are already some better approaches?

I see that I can map an ok value to any result I want by using .andThen. I can use unwrapOr to replace every error by given value.

But what about mapping an error value to an ok value dymically? It's sound quite useful that we want to recover after error and e.g. provide a default value for one type of error and left error as is for other type.

e.g.

const occupationResult: Result<string, NotFoundError | ConnectionError> = await getUserOccupation();

const safeOccupationResult = occupationResult.someErrorMappingFunction(
  (error: NotFoundError | ConnectionError) => {
    if (err instanceof NotFoundError) {
      return ok("User not found");
    } else {
      return error;
    }
  }
);


// comparison to promises:
// a - rejected promise
const a = Promise.reject("an error");
// b - resolved promise
const b = a.catch(err => 33);
// c - rejected promise
const c = a.catch(err => Promise.reject("other error"));

how I could achieve currently the result that my imaginary function someErrorMappingFunction do?

After a lot of research into error handling in TypeScript, I've pretty much settled on this library as being the best option for our use. However, I am running into a major blocker. My existing codebase is built using async functions and await, but after converting the return type of a method from a Promise to ResultAsync<something, someError>, the compiler complains that

Type 'typeof ResultAsync' is not a valid async function return type in ES5/ES3 because it does not refer to a Promise-compatible constructor value.

I am targeting ES5 in my tsconfig, because this is going to run in a browser, but it doesn't make sense to me that it would not be promise compatible. This seems very basic so I figure I must be missing something here; is there a config option or something I may be overlooking? For the record, I'm using neverthrow 3.1.2.

As an example, even this basic method throws an error:

public async testAsync(): ResultAsync<string, Error> { return okAsync("Hello world!"); }

Just writing this here publicly to see if others agree or disagree.

I think it would be nice to have a utility function that has the following signature:

Promise<Result<T, E>> => ResultAsync<T, E>

Since sometimes it's easier to write a function using async/await syntax.

Additionally, I am also thinking it would be nice to have another utility function with the following signature:

Result<T, E> => ResultAsyncT, E>

I guess the above would be called intoResultAsync or something like that?

Curious to hear what folks think.

Hey supermacro, thanks so much for this library :) I'm starting to use it in one of my projects and love it so far! Anyway I was just wondering if you considered using function overloading for the chain API? I'm imaging something similar to the pipe API in fp-ts.

Here is kinda what I'm thinking although this has not been tested:

export function chain<T1, T2, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Promise<Result<T2, E>>): Promise<Result<T2, E>>;
export function chain<T1, T2, T3, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Promise<Result<T3, E>>): Promise<Result<T3, E>>;
export function chain<T1, T2, T3, T4, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Ok<T3, E> | Err<T3, E> | Promise<Result<T3, E>>, r4: (v: T3) => Promise<Result<T4, E>>): Promise<Result<T4, E>>;
export function chain<T1, T2, T3, T4, T5, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Ok<T3, E> | Err<T3, E> | Promise<Result<T3, E>>, r4: (v: T3) => Ok<T4, E> | Err<T4, E> | Promise<Result<T4, E>>, r5: (v: T4) => Promise<Result<T5, E>>): Promise<Result<T5, E>>;
export function chain<T1, T2, T3, T4, T5, T6, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Ok<T3, E> | Err<T3, E> | Promise<Result<T3, E>>, r4: (v: T3) => Ok<T4, E> | Err<T4, E> | Promise<Result<T4, E>>, r5: (v: T4) => Ok<T5, E> | Err<T5, E> | Promise<Result<T5, E>>, r6: (v: T5) => Promise<Result<T6, E>>): Promise<Result<T6, E>>;
export function chain<T1, T2, T3, T4, T5, T6, T7, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Ok<T3, E> | Err<T3, E> | Promise<Result<T3, E>>, r4: (v: T3) => Ok<T4, E> | Err<T4, E> | Promise<Result<T4, E>>, r5: (v: T4) => Ok<T5, E> | Err<T5, E> | Promise<Result<T5, E>>, r6: (v: T5) => Ok<T6, E> | Err<T6, E> | Promise<Result<T6, E>>, r7: (v: T6) => Promise<Result<T7, E>>): Promise<Result<T7, E>>;
export function chain<T1, T2, T3, T4, T5, T6, T7, T8, E>(r1: Promise<Result<T1, E>>, r2: (v: T1) => Ok<T2, E> | Err<T2, E> | Promise<Result<T2, E>>, r3: (v: T2) => Ok<T3, E> | Err<T3, E> | Promise<Result<T3, E>>, r4: (v: T3) => Ok<T4, E> | Err<T4, E> | Promise<Result<T4, E>>, r5: (v: T4) => Ok<T5, E> | Err<T5, E> | Promise<Result<T5, E>>, r6: (v: T5) => Ok<T6, E> | Err<T6, E> | Promise<Result<T6, E>>, r7: (v: T6) => Ok<T7, E> | Err<T7, E> | Promise<Result<T7, E>>, r8: (v: T7) => Promise<Result<T8, E>>): Promise<Result<T8, E>>;

export async function chain(
  start: Promise<Result<any, any>>,
  ...transforms: any
): Promise<Result<any, any>> {
  return await (transforms as Array<(v: any) => Promise<Result<any, any>>>).reduce(
    async (current, f) => {
      const mapped = await (await current).asyncMap(f);
      return mapped.andThen((inner) => inner);
    },
    start,
  );
}

Let me know your thoughts!

Hi there,

I know that this has come up a few times in a few different ways, but I'm coming at it from a different point of view.

One of the major benefits of async/await is that it helps to make the code more readable. You get to write more procedural code that is more obvious to read and maintain, instead of complicated call stacks.

For example, the following are the same:

return doSomething()
    .then(result => doSomethingElse(result))
    .then(next => next.abc);
// -----
const result = await doSomething();
const next = await doSomethingElse(result);
return next.abc;

The second of which is much more obvious for someone to follow.

Neverthrow is awesome, but the fact that it not only doesn't work with async/await but also doesn't work well with Promise makes it awkward to use. If I start to use it in a call stack I end up having to use it throughout the entire call stack, or else using things like _unsafeUnwrap() to escape from it.

This means that it's more difficult to introduce into a project. I have to start from the outside and work in, because I can't easily convert a layer until all of the callers are already expecting ResultAsync objects to be returned. And this is especially big if you consider infrastructure-level layers. For example, if I were to update a database layer to use neverthrow instead of exceptions then I've got to update the entire application in order to make that work!

The frustrating thing is that Promise<Result<T, E>> almost works fine. It's just the fact that the various methods on it - map, andThen, etc - don't allow for async methods that cause problems.

For example, the following would - to me, at least - be a much easier to understand and maintain alternative:

return doSomething() // function doSomething() : ResultAsync<string, Error>
    .andThen(doSomethingElse) // function doSomethingElse(string) : ResultAsync<foo, Error>
    .map(next => next.abc());
// -----
const result = await doSomething(); // async function doSomething() : Promise<Result<string, Error>>
const next = await result.andThenAsync(doSomethingElse); // async function doSomethingElse(string) : Promise<Result<foo, Error>>
return await next.mapAsync(n => n.abc());

where in this case the andThenAsync and mapAsync functions take async functions and return Promise<Result<T, E>> instead. And, importantly, it would mean that I can replace any individual part of the call chain with neverthrow without needing to replace all of it.

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | prettier (source) | 2.2.1 -> 2.8.1 | | | | |

Release Notes

// Input
$display-breakpoints: map-deep-merge(
  (
    "print-only": "only print",
    "screen-only": "only screen",
    "xs-only": "only screen and (max-width: #{map-get($grid-breakpoints, "sm")-1})",
  ),
  $display-breakpoints
);

// Prettier 2.8.0
$display-breakpoints: map-deep-merge(
  (
    "print-only": "only print",
    "screen-only": "only screen",
    "xs-only": "only screen and (max-width: #{map-get($grid-breakpoints, " sm
      ")-1})",
  ),
  $display-breakpoints
);

// Prettier 2.8.1
$display-breakpoints: map-deep-merge(
  (
    "print-only": "only print",
    "screen-only": "only screen",
    "xs-only": "only screen and (max-width: #{map-get($grid-breakpoints, "sm")-1})",
  ),
  $display-breakpoints
);

class Foo {
  accessor foo: number = 3;
}

// Input
.background-gradient(@​cut) {
    background: linear-gradient(
        to right,
        @​white 0%,
        @​white (@​cut - 0.01%),
        @​portal-background @​cut,
        @​portal-background 100%
    );
}

// Prettier 2.6.1
TypeError: Cannot read properties of undefined (reading 'endOffset')

// Prettier 2.6.2
.background-gradient(@​cut) {
  background: linear-gradient(
    to right,
    @​white 0%,
    @​white (@​cut - 0.01%),
    @​portal-background @​cut,
    @​portal-background 100%
  );
}

foo(await bar());

const regex = /.*/ms;

const element = <p>{/w/.test(s)}</p>;

class A extends B {
  #privateMethod() {
    super.method();
  }
}

// Input
type Foo =
  Foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo extends []
    ? Foo3
    : Foo4;

// Prettier 2.5.0
type Foo = Foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo extends [

]
  ? Foo3
  : Foo4;

// Prettier 2.5.0 (tailingCommma = all)
// Invalid TypeScript code
type Foo = Foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo extends [
  ,
]
  ? Foo3
  : Foo4;

// Prettier 2.5.1
type Foo =
  Foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo extends []
    ? Foo3
    : Foo4;

// Input
<Component>
  <:named></:named>
</Component>

// Prettier 2.5.0
<Component>
  <:named />
</Component>

// Prettier 2.5.1
<Component>
  <:named></:named>
</Component>

// Input
@​forward "library" as btn-*;

// Prettier 2.4.0
@​forward "library" as btn- *;

// Prettier 2.4.1
@​forward "library" as btn-*;

$ ls
1.js  1.unknown

Configuration

📅 Schedule: Branch creation - "every 1 months on the first day of the month" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | @types/node (source) | 14.17.4 -> 14.18.36 | | | | |

Configuration

📅 Schedule: Branch creation - "every 1 months on the first day of the month" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | testdouble | 3.16.3 -> 3.16.8 | | | | |

Release Notes

Configuration

📅 Schedule: Branch creation - "every 1 months on the first day of the month" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

Result is broken. It doesn't track ok type changes.

import { Result, ok, err } from 'neverthrow';

const a: Result<number, number> = err(1);
const b: Result<number, number> = a.orElse(() => ok('A'));
console.log(b);

$ npx tsc
$ node main.js
Ok { value: 'A' }

The ok type of b is string, but TypeScript thinks it is number.

ResultAsync is fine. It rejects ok type changes.

import { ResultAsync, okAsync, errAsync } from 'neverthrow';

const a: ResultAsync<number, number> = errAsync(1);
const b: ResultAsync<number, number> = a.orElse(() => okAsync('A'));
b.then((r) => console.log(r));

$ npx tsc
main.ts:4:7 - error TS2322: Type 'ResultAsync<number, unknown>' is not assignable to type 'ResultAsync<number, number>'.
  Type 'unknown' is not assignable to type 'number'.

4 const b: ResultAsync<number, number> = a.orElse(() => okAsync('A'));
        ~

main.ts:4:55 - error TS2769: No overload matches this call.
  Overload 1 of 3, '(f: (e: number) => Result<number, unknown>): ResultAsync<number, unknown>', gave the following error.
    Type 'ResultAsync<string, never>' is not assignable to type 'Result<number, unknown>'.
      Type 'ResultAsync<string, never>' is missing the following properties from type 'Err<number, unknown>': error, isOk, isErr, asyncAndThen, and 3 more.
  Overload 2 of 3, '(f: (e: number) => ResultAsync<number, unknown>): ResultAsync<number, unknown>', gave the following error.
    Type 'ResultAsync<string, never>' is not assignable to type 'ResultAsync<number, unknown>'.
      Type 'string' is not assignable to type 'number'.
  Overload 3 of 3, '(f: (e: number) => Result<number, never> | ResultAsync<number, never>): ResultAsync<number, never>', gave the following error.
    Type 'ResultAsync<string, never>' is not assignable to type 'Result<number, never> | ResultAsync<number, never>'.
      Type 'ResultAsync<string, never>' is not assignable to type 'ResultAsync<number, never>'.
        Type 'string' is not assignable to type 'number'.

4 const b: ResultAsync<number, number> = a.orElse(() => okAsync('A'));
                                                        ~~~~~~~~~~~~

  node_modules/neverthrow/dist/index.d.ts:19:45
    19     orElse<R extends Result<T, unknown>>(f: (e: E) => R): ResultAsync<T, InferErrTypes<R>>;
                                                   ~~~~~~~~~~~
    The expected type comes from the return type of this signature.
  node_modules/neverthrow/dist/index.d.ts:20:50
    20     orElse<R extends ResultAsync<T, unknown>>(f: (e: E) => R): ResultAsync<T, InferAsyncErrTypes<R>>;
                                                        ~~~~~~~~~~~
    The expected type comes from the return type of this signature.
  node_modules/neverthrow/dist/index.d.ts:21:18
    21     orElse<A>(f: (e: E) => Result<T, A> | ResultAsync<T, A>): ResultAsync<T, A>;
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The expected type comes from the return type of this signature.


Found 2 errors in the same file, starting at: main.ts:4

Bumps minimatch from 3.0.4 to 3.1.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I want to re-export the combine functions like this

import { Result } from 'neverthrow';
export function combine<T extends Result<unknown, unknown>[]>(resultList: T) {
    return Result.combine(resultList);
}

It works fine, but the d.ts file becomes so huge that it entirely hangs the IDE and the typescript compiler, so it's impossible to use that declaration file in any other project.

I don't know why that happens, maybe it's a tsc issue or something else, but it was working fine before version 5.1.0.