Keeping non-enumerable properties

[ehmicky]

At the moment, non-enumerable properties are removed from the return value.

On one hand:

• Most functional utilities iterate on objects using standard for ... in, Object.keys(...), etc. which ignore non-enumerable properties. Object spreading { ...object } itself removes non-enumerable properties.
• The concept of a property being non-enumerable implies that it should not be iterated when being copied over.
• Non-enumerable properties are much less common on plain objects than on class instances, and this library is meant for plain objects.

On the other hand, some users might not expect non-enumerable properties removal as a side effect of this library. For example:

• excludeKeys(object, ['one']): this would remove object.two if it is non-enumerable, even though the user operation only intended to exclude object.one.
• includeKeys(object, ['one']): this would not include object.own if it is non-enumerable, even though the user explicitly requested to include it.
• For predicate functions, the user intent is less clear.

@sindresorhus What are your thoughts on this?

[sindresorhus]

By default, I think it makes sense to ignore enumerable properties (it's an edge-case anyway), but I guess it could be useful to add an opt-in option like preserveNonEnumerableProperties.

[sindresorhus]

Maybe we should look at what other packages do, like Loads.filter or even https://github.com/tc39/proposal-iterator-helpers