Module '"utility-types"' has no exported member 'Nullish'.

[flisboac]

Description

Nullish and isNullish are not exports for this library, yet the README says they are.

Steps to Reproduce

1. Install utility-types
2. Try to import Nullish
3. Try to compile, or verify syntax through e.g. tsc, eslint, etc.
4. tsc complains, with the message Module '"utility-types"' has no exported member 'Nullish'.

Example:

import { Nullish } from 'utility-types';

// ....

Expected behavior

To have Nullish and isNullish.

Suggested solution(s)

If Nullish and isNullish were indeed removed, please consider this issue a feature request.

Verifying for nullish values is such a common practice that having a specific type and a guard for it is perfectly justifiable. I wanted to use this library so that I don't have to re-implement the same pedestrian thing over and over again, in every project. :P

isNullish could help eliminate the possibility for null or undefined in specific parts of the code, in case the actual non-nullish type of what you're filtering is not of special interest. An example:

// An example of how isNullish could be used
// In fact, this could very much be a guard in the library! ;)
function isNotNullish<T>(value: T): value is Exclude<T, Nullish> {
  return !isNullish(value);
}

// And then:
// (e.g. `values` contains extracted property values, from an user-provided object)
declare values: Array<string | number | Nullish>;
const filteredValues = values.filter(isNotNullish); // effectively, `Array<string | number>`

// Or even:
function filterValueSeries<T>(values: T[]): void {
  values.filter(isNotNullish).forEach(processValueSeries);
}

isNullish may be especially important in filters, or in callbacks, where the parameter and/or return type may not be statically known, but you just want to be sure they're "filled in" (in which case you just negate the guard's return value). An example:

// Suppose this comes from an object's property, and the object itself is from some unreliable source (e.g. JSON value).
// Perhaps the date value is optional; It may be filled in, or be null, or be completely absent from the object.
// Hence why it may be typed as such.
// But again, this is just an example!
type RawDate = string | number | undefined | null;

// Supposing rawDate as string is guaranteed to be a valid date string in this context
function extractDate(rawDate: RawDate): Date | undefined {
  if (!isNullish(rawDate)) {
    // Typescript will be smart enough to deduce that `rawDate` has type `string | number | Date`
    // at this point of the code.
    return new Date(rawDate);
  }
  return undefined;
}

Also, having a standard way for checking nullish values, which you can reuse across projects, is valuable in and of itself.

Project Dependencies

• Utility-Types Version: 3.10.0
• TypeScript Version: 4.4.3
• tsconfig.json: (not really needed)