One of the main reasons why I use lodash is because it does a lot of null/undefined checking for me. For example, I would use _.some(x, ...) instead of the native x.some(...) because lodash will check if x is null (and if so return false in this case), but the native version will throw an error if x is null. And I would much rather write _.some(x, ...); than _.isNil(x) ? x.some(...) : false;.

However, this won't work when strictNullChecks are enabled because the type definition for _.some doesn't allow for null/undefined values in the first parameter. So if I have x: number[] | undefined, I get a compiler error. So for now I need to disable strictNullChecks in order to use lodash.

I'm proposing that we update the following functions definitions to accept null and undefined values:

• all Array functions
• all Collection functions
• all Object functions
• Implicit wrapper: _()
• Explicit wrapper: _.chain()

So for example, the _.some definition would change to:

some<T>(
    collection: List<T> | null | undefined,
    predicate?: ListIterator<T, boolean>
): boolean;

some<T>(
    collection: Dictionary<T> | null | undefined,
    predicate?: DictionaryIterator<T, boolean>
): boolean;

some(
    collection: Object | null | undefined,
    predicate?: ObjectIterator<any, boolean>
): boolean;

etc.

If we agree that this is a good thing to do, I can submit a PR. But first, is anyone aware of any use cases where this would cause problems?

• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @bczengel @chrootsu @stepancar @ericanderson
• I tried using the @types/xxxx package and had problems.