Most Lodash functions accept null & undefined

Lodash libdefs does not always accept null or undefined when Lodash most of the time is totally fine with them. I made a small script to skim trough Lodash and check out which ones does not accept null or undefined and there were only handful of them. here is the script i used on lodash documentation page:

_.map(_, (value, key) => {
  if (typeof value !== 'function') {
    return;
  }
  try {
    value(..._.times(value.length, () => null));
  } catch (e) {
    return key;
  }
}).filter(v => v);

and here are the actual functions which failed when passing nulls:

[
  "after",
  "ary",
  "before",
  "bind",
  "curry",
  "curryRight",
  "debounce",
  "defer",
  "delay",
  "flip",
  "memoize",
  "negate",
  "once",
  "partial",
  "partialRight",
  "rearg",
  "rest",
  "spread",
  "tap",
  "throttle",
  "thru",
  "unary"
]

Are Lodash libdefs strict on nulls by design, or is it just inaccuracy? All the other functions returned something more or less meaningful when passing in nulls: null, undefined, empty array or object. Some returned Window or -1 etc. Return values vary a bit depending if passing in null or undefined

[villesau]

yep 👍

[villesau]

@AndrewSouthpaw I think good rule of thumb could be to try distinguish wether null or undefined is somewhat special value or not for the function. If undefined and null are similar values than any other value, no need to have special handling for them. For example with function eq, I don’t see that undefined or null differs from any other values or types like number or string: For that function all of them are just values. In this case I took it into account and thought returning boolean is just enough. see test_does-not-fail-on-null-v4.x.x.js:398. But then again if we look at invert, it’s not clear that the function returns (an empty) object in case of null or undefined and that’s imo somewhat special behaviour around undefined or null cases which can be taken into account on the libdef level.

Then there is ofc maintainability aspect. In case of Lodash, I think it’s such a stabilised library that things are not likely to change that often. This makes it acceptable to have more specific definitions than in some younger libs where some corner cases might not be taken into account.