Ping @leebyron - very small change with very big performance implications

Sorry for missing this! Thanks so much for the fix.

I'll clear up the dts noise first and then get this in

Hmm, I actually want to understand this a bit better.

There are cases where we use is() to determine value equality - when not knowing true equality would result in an incorrect state, and there are other cases where we use === to determine cheap equality, where we're optimizing what would otherwise be a correct but more expensive operation.

This is similar to myMap.set() where when setting a new value, it's always correct to return a new Map with the provided value set, and we use === as a very cheap optimization to return the same map.

The reason we don't use is() for the optimization opportunity is that it does a full walk of any data structures provided.

I think this case you're updating is an optimization opportunity rather than a result correctness.

However, I think it's safe to use the is() for the optimization specifically for mergeDeep because mergeDeep will always walk over iterables and only the scalar (or at least non-iterable) leafs will be compared and merged.

I think we should find a way to apply this change only in the condition that you're using mergeDeep

Ah you're right - great solution! Thanks!