[zshannon]

Fixes #146 and not sure if adding the same Falsy guard to is.falsy helps there because I'm just using is.truthy as a .filter but happy to add the Falsy annotation to is.falsy too if helpful

[sindresorhus]

I think it would be better to participate in #146 first. There are unanswered questions there.

Although there are restrictions on using is.truthy() as a type guard function

but in what cases would it be useful though?

[sindresorhus]

It doesn't look like you ran the tests before submitting.

[zshannon]

It doesn't look like you ran the tests before submitting.

You're right, sorry about that, updated with passing tests. Also added 0n to Falsy.

Although there are restrictions on using is.truthy() as a type guard function

I don't follow what "restrictions on using is.truthy() as a type guard function" means so not sure how to add to the conversation there. I also don't know "in what cases would [is.falsy as a typeguard] be useful". But is.truthy as a typeguard (this PR) is something I use constantly so can easily speak to that if it's unclear :)

[sindresorhus]

I don't follow what "restrictions on using is.truthy() as a type guard function" means

// @younho9

[sindresorhus]

My comment about is.falsy clearly applies to is.truthy too. The gist of it is "The narrowing is still pretty wide.". How is such a wide narrowing more useful than unknown? What can you now use is.truthy for that was not possible before the type-guard?

[younho9]

I thought is.truthy has some restrictions in the following case.

export type Falsy = false | 0 | 0n | '' | null | undefined;

const isTruthy = <T>(value: T | Falsy): value is T => Boolean(value);
const isFalsy = (value: unknown): value is Falsy => !Boolean(value);

declare const number_: number;

if (isTruthy(number_)) {
    number_ // number
} else {
    number_ // never
}

if (isFalsy(number_)) {
    number_ // 0
} else {
    number_ // number
}

is.falsy could be useful to narrow falsy value from primitive type, but is.truthy is not.

I think using it with a filter could be one of use case.

[younho9]

Also, when value has falsy type, is.truthy couldn't find truthy value.

declare const falsyValue: null;

if (isTruthy(falsyValue)) {
    falsyValue // null, expected never
} else {
    falsyValue // never, expected null
}

if (isFalsy(falsyValue)) {
    falsyValue // null
} else {
    falsyValue // never
}

TypeScript Playground

[zshannon]

I use isTruthy as a typeguard with filters everywhere, pattern is like this:

type Tipe = { ... }
const maybes: Array<Tipe | undefined | null> = await Promise.allSettled([ ... calls that may fail ... ]).map(({ value }) => value)
maybes.filter(isTruthy).map(X => { ... X is Tipe here ... })

I can guess from the defaults in unicorn that @sindresorhus is not a fan of passing eg isTruthy directly into .filter like this but it's still useful even with the extra maybes.filter(maybe => isTruthy(maybe)) characters ;)

[sindresorhus]

Ah, I get it now. So it's really just about narrowing away undefined and null.

[sindresorhus]

Also, when value has falsy type, is.truthy couldn't find truthy value.

Do you know why that happens?

[sindresorhus]

Seems like this change could be useful even with the mentioned limitations.

[sindresorhus]

@zshannon Could you also apply this to is.falsy?