Apply clone option to target object

[creativeux]

closes #208 closes #186

• Added ternary for initializing the destination object based on the clone option.
• Added 2 unit tests... 1 to test that target type info is retained, and another to ensure that target memory pointer is maintained when clone is set to false.

[TehShrike]

This looks good. One request – could you add a test that asserts that when merge.all is called with { clone: true }, the first element is mutated/returned?

[creativeux]

could you add a test that asserts that when merge.all is called with { clone: true }, the first element is mutated/returned?

Great call, I hadn't used that entrypoint so didn't think to change it. I made the change, but it required a few more lines to change to make it elegant and aligned with the code style in place. The firstArrayEntry() method is there to avoid chained ternaries which can be confusing to read, and I moved the logic to determine if the destination should be a new object or a target object into a function.

Let me know if you'd like any add'l changes!

[RebeccaStevens]

I like it but I am a little worried about backwards compatibility. As is, this would definitely need to be released as a new major version.

[creativeux]

I like it but I am a little worried about backwards compatibility. As is, this would definitely need to be released as a new major version.

You're probably right. This is an awkward one because it sounds like it is technically a bug fix because the API "lies" to the consumer about how the clone option is applied, but fixing it potentially breaks consumers whose code relies on the bug being there. I'll let you guys duke it out 😉

[TehShrike]

Yup, this would be a breaking change. I'm thinking to pair it with removing the deprecation warning from the clone flag

[RebeccaStevens]

~I've changed my mind on liking this.~ [I'm back to liking it now]

I like the idea behind it but this is definitely a breaking change that I can see a lot of push back happening on if it goes live.

The current implementation of the clone flag makes it so that if set to false, objects will be directly copied over to the resulting merged object. The new behavior in this MR as is makes it so that when the clone flag is false, the target option will be mutated.

These two behaviors are very different and I don't think it would be a good idea to switch from one to the other using the same flag.

The issue with having this behavior on the "clone" flag is that it that it is valid to want to both clone and not mutate the any of the parameters.

I would be best to put this behavior behind a new flag called "mergeWithTarget".

I just made a new issue #212 with my proposal for the clone behavior.

[creativeux]

@RebeccaStevens I lied about how long it would take. My wife started watching The Bachelorette and that was my cue to zone out. Let me know if this addresses the concerns re: clone vs mergeWithTarget.

[RebeccaStevens]

Looks good to me :+1:

[RebeccaStevens]

@creativeux do you want to mark this as closes #186?

[creativeux]

@TehShrike and @RebeccaStevens - I caught a bug with my in-use fork of this where the merge fails in the case that a target is undefined. I pushed a fix and a unit test to ensure that there is always an emtpy object or array to merge into if the target is undefined.