prefer-reflect: Reflect.deleteProperty considered harmful

The rule tells that:

Reflect.deleteProperty effectively deprecates delete keyword

Putting conciseness of delete and “Map should be used instead” points aside, given strict mode enabled and considering only property references, Reflect.deleteProperty returns result of [[Delete]] call (boolean), but does not throw on false, unlike delete operator does.

Throwing if deletion fails (non-configurable property, Proxy trap) is what modern JavaScript does. Not throwing causes confusion.

Quoting @nzakas on prefer-reflect:

This rule should warn only for direct replacements.

I think Reflect.deleteProperty should be removed from the rule.

EDIT: same goes for preventExtensions and setPrototypeOf.

[nzakas]

A little bit more background:

I think we may have moved too fast in creating this rule, and I take responsibility for that. I don’t think any of us fully understood the purpose of Reflect and why those methods exist as separate from their Object equivalents. Now that I do understand, I feel like this entire rule is misguided, as the Reflect methods are not actually intended to replace the Object counterparts, but rather as low-level primitives to be used with proxies in order to replicate the default behavior of various previously existing functionality.

So, while I’m not opposed to updating the documentation, I’m more of the mind that this rule is does more harm than good by implying a relationship between Reflect and Object that doesn’t necessarily exist.

[nzakas]

That’s why I’m saying maybe the whole rule should be removed. I don’t think it makes sense to just remove a subset.