-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "clone" option #28
Comments
Interesting. So the issue is that you (quite reasonably) expected that all values would be recursively copied, and it definitely doesn't do that. The docs don't claim that it recursively copies, but it sure does look like it would. I'm tempted to add this behavior because it's what I'm more likely to want, but I'm averse to adding it because it would be a breaking change. In any case, if the change doesn't get added and #29 isn't merged, the documentation should at least be made clearer on this behavior. Any other opinions? Is recursive copying worth the breaking change? |
Yes it will break the present behavior and sure its major change. But as the document states that a new merged object would be created then expectations are that the changes in new object would not affect the original objects. If someone wants the current behavior (without cloning) then generally extend is used. As the change is major I think more suggestions are required. |
Passing merge(x, y, clone) and default value for |
Yeah, that would probably be the way to go. #37 adds an options object - a |
👍 |
Published as 1.2.0 |
here is the test
Is this intentional behavior? I think in most of the cases source object should be cloned.
The text was updated successfully, but these errors were encountered: