fix: avoid isObject for internal use

[aleclarson]

Description

Using isObject internally is hostile to any use case in need of Object.create(null), so we'll use isPlainObject instead.

Affected functions include:

• assign
• crush
• keys

What does this mean?

When an object created with Object.create(null) is nested in the argument to assign, crush, or keys, it will be treated as if it was created with {}. In the case of assign, any time such an object is assigned to, the resulting clone of the object will have a null prototype as expected.

Checklist

• Changes are covered by tests if behavior has been changed or added
• Tests have 100% coverage
• If code changes were made, the documentation (in the /docs directory) has been updated

Resolves

Resolves sodiray/radash#409

[aleclarson]

Point of discussion

This line changes the behavior of assign in two subtle ways:

1. It copies non-enumerable properties into the new object.
2. It copies the prototype into the new object, potentially calling a class constructor.

For these reasons, this is a breaking change, BUT the behavior of assign is so woefully underspecified that we could probably get away with publishing this in a minor version.

The question is, “what's the intuitive behavior?” One might argue it's whatever aligns with Object.assign, as this is basically a recursive version of that.

The best course of action is likely to implement a simpler variant of cloneObject that does { ...initial } unless an object created with Object.create(null) is found, in which case, a mixture of Object.create(null) & Object.assign is performed.

[aleclarson]

After writing that out, the answer is clear that what I described in the last paragraph is how it should work.