The issue with this is that lodash avoids erroring as far as possible, and most functions will account for cases where null and undefined are passed into them. Adding such warnings will add a lot of noise to the documentation, so I'm not sure if this is the right way to go.

Hi @bnjmnt4n, thanks for your reply.

I have to disagree that accurate documentation is noise.

On the other hand, a library being unwilling to document its behavior causes my code to be full of noise guarding against things like that. I have to treat it as an implementation detail, possibly even unintended, that what's documented as a non-optional Object argument can actually be undefined, null, or even omitted instead. I don't understand the logic of intentionally enabling that behavior, presumably so it's unnecessary to fill the calling code with noisy guards, and then not documenting it so it can be relied on.

You're comfortable pushing code to production that relies on undocumented behavior that could change in a patch release while complying with semver?

While I don't see an argument for not making the documentation accurate, there may be a way to avoid what you fear as noise. But I don't know what capabilities and constraints are involved in how you generate the documentation.