This change will allow _unsafeUnwrapErr to be a valid way of consuming the result. The rule already allows _unsafeUnwrap.
This change is needed because currently there is no simple way to assert an error message in a unit test for example. When using _unsafeUnwrapErr, the linter shows this message:
Result must be handled with either of match, unwrapOr or _unsafeUnwrap. eslint:neverthrow/must-use-result
To avoid this, I had to do this in unit tests:
let error: Error = new Error();
result.match(
() => {},
(e) => {
error = e;
});
expect(error.message).toBe("The object is missing");
Which is a lot of boilerplate for a small assertion.
Using _unsafeUnwrap will obviously not work with an Err.
Other changes:
Added a couple of unit tests for _unsafeUnwrap and _unsafeUnwrapErr.
This change will allow
_unsafeUnwrapErr
to be a valid way of consuming the result. The rule already allows_unsafeUnwrap
.This change is needed because currently there is no simple way to assert an error message in a unit test for example. When using
_unsafeUnwrapErr
, the linter shows this message:To avoid this, I had to do this in unit tests:
Which is a lot of boilerplate for a small assertion.
Using
_unsafeUnwrap
will obviously not work with an Err.Other changes:
_unsafeUnwrap
and_unsafeUnwrapErr
.