fix(utils): compare Date values by time in deepEqualObj - #16749
fix(utils): compare Date values by time in deepEqualObj#16749yfwmaniish wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 5157edf The changes in this PR will be included in the next version bump. This PR includes changesets to release 83 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for the contribution! Initial automated review looks good. The contributor fixes a real bug in the deepEqualObj utility: JavaScript Date instances expose no own enumerable keys, so the existing key-length/loop comparison treated any two Date values as equal regardless of their actual time. The fix inserts a Date guard before the key-based path, correctly delegating to getTime() comparison and returning false when exactly one argument is a Date. The logic is sound, all existing test cases still pass, and four new cases cover equal dates, unequal dates, dates nested in plain objects, and Date-vs-plain-object cross-type comparisons. Checklist: - Changeset included and correctly formatted as a patch for @medusajs/utils. - Tests added in packages/core/utils/src/common/tests/deep-equal-obj.spec.ts. - Conventions followed: no semicolons, double quotes, 2-space indent, no issue/PR references in code comments. - No security, performance, or correctness concerns. Note (non-blocking): the PR body uses the section headers "Fix" and "Tests" rather than the template's "How" and "Testing". The content is substantive and satisfies the intent of both sections. Additionally, contribution guidelines ask for a linked issue for non-trivial fixes; this PR lacks one, though the description is self-contained and documents the bug thoroughly. Triggered by: new PR opened |
What
deepEqualObjreports two differentDatevalues as equal:Why
After the primitive/null guards, the function compares two objects purely by their own enumerable keys:
Dateinstances have no own enumerable keys, so for any two dates both key lists are[], the lengths match, the loop body never runs, and the function returnstrue. This matters in practice because Medusa entities carryDatefields everywhere (created_at,updated_at, …), so a change-detection comparison on such objects can silently miss a differing date.Fix
Compare
Datevalues by their time before falling through to the key-based comparison:A
Datecompared to a non-Dateobject is now correctly unequal, and equal dates stay equal. Plain-object comparison is unchanged.Tests
Added a
deepEqualObjcase covering equal/unequal dates, nested date fields, and Date-vs-plain-object. Verified all existing cases still pass.