`Object.keys` fallback is not correct.
jdalton opened this issue · 9 comments
I noticed while taking a peek at levelup, that it depends on xtend. And then noticed that xtend's objectKeys method isn't an equiv for Object.keys.
A proper polyfill is non-trivial and is actually more complex then the one referenced. However, it's up to you how much support you want to extend (no pun intended). The bare minimum would be simply adding hasOwnProperty checks.
Because xtend is immutable and treats all arguments as sources to merge into targets it only makes sense for plain objects and not things with prototypes that have enumerable properties.
The objectKeys fallback also does not gaurd against Object.prototype pollution as that's out of scope.
I'm curious to see what browsers are effected by the dont enum bug. I don't think I've run into that one before.
I've seen extend like methods used for things like xtend(grandchildCtor.prototype) which could have non Object.prototype inherited props. The [[DontEnum]] bug affects IE < 9 and is handled in some way by libs like PrototypeJS, Dojo, MooTools, YUI, Lo-Dash, and es5Shim.
Filtering own properties of source objects also aligns with ES6's Object.assign.
This extend is immutable so can't be used to extend prototype objects. Which is unfortunate.
I'll accept patch to use object-keys though
cc @ljharb :D
I've updated the code to a use a real object-keys shim.