Docs: Explain why `{}.hasOwnProperty.call` is recommended

A coworker just cleaned up a bunch of lint errors in the project, and left this headscratcher in the codebase:

for(let key in obj) {
      if ({}.hasOwnProperty.call(obj, key)) {
          // ...
      }
}

When asked what was going on here and why not just use obj.hasOwnProperty(key) or even Object.prototype.hasOwnProperty.call(obj, key), he pointed to the docs for guard-for-in, which, sure enough, recommends this pattern as a solution.

I dug through the history of the docs page, assuming to maybe find it as part of a commit that expanded the detection capabilities of the rule (and the docs would demonstrate just how crazy you could write the call and still satisfy the rule), but it turns out it is in fact recommended as a “best practice”: https://github.com/eslint/eslint/commit/551335eedf62261299af7aafdfc896b3aef8de67

I’d recommend the docs page for this rule be amended to explain exactly why this sort of gymnastics is demonstrated over a simpler approach. Is it meant to avoid an edge case where hasOwnProperty is defined and thus overridden higher in the prototype chain?

[ljharb]

(fwiw, this is why the Airbnb style guide and virtually every “best practice” i’ve seen discourages use of for..in - Object.keys(obj).forEach does not have this problem)

[not-an-aardvark]

To answer your question, Object.prototype.hasOwnProperty.call is generally used for two reasons:

1. hasOwnProperty is defined on the object as something else, as you mentioned:

   var someObject = {foo: 'bar', hasOwnProperty: 5};
   someObject.hasOwnProperty('foo') // throws a TypeError
   

2. The object in question is being used as a map and doesn’t inherit from Object.prototype, so it doesn’t have hasOwnProperty:

   var someObject = Object.create(null);
   someObject.hasOwnProperty('foo'); // throws a TypeError
   

See also: no-prototype-builtins