Skip to content
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

Since v4.0.0, _.isEqual is not consistent over object properties ordering #1758

Closed
mickaeltr opened this issue Jan 13, 2016 · 14 comments

Comments

@mickaeltr
Copy link

commented Jan 13, 2016

Hello,

Since I have upgraded to Lodash v4.0.0, _.isEqual fails depending on object properties ordering. See the following example:

var object1 = {a: "A", b: null};
var object2 = {b: null, a: "A"};
var object3 = {a: "A", b: null};
console.log(_.isEqual(object1, object2)); => false
console.log(_.isEqual(object1, object3)); => true

Thanks

@jdalton jdalton added the bug label Jan 13, 2016

@jdalton

This comment has been minimized.

Copy link
Member

commented Jan 13, 2016

Ew, super gross bug. Thank you for finding it.

@jdalton jdalton closed this in 1ef4807 Jan 13, 2016

@jdalton

This comment has been minimized.

Copy link
Member

commented Jan 15, 2016

Added test c16bd07.

@ggreer

This comment has been minimized.

Copy link

commented Jan 23, 2016

I think it would be a really really good idea to publish 4.0.1.

More people are running into this bug and reporting it (#1810, #1859, #1863). I'd have added to that list had I not searched beforehand. This bug caused me hours of frustration. I thought, "There's no way this can be a bug in lodash. It has to be my own code." I was mistaken. :(

@verybluebot

This comment has been minimized.

Copy link

commented Sep 26, 2017

still having exact same issue in 4.17.4... is this issue still open?

@jdalton

This comment has been minimized.

Copy link
Member

commented Sep 26, 2017

Hi @verybluebot, it works for me based on the unit test added above.

@verybluebot

This comment has been minimized.

Copy link

commented Sep 26, 2017

@waratah

This comment has been minimized.

Copy link

commented Oct 24, 2017

Just a note for those that end up here...

Don't forget to copy your original object using deep clone or else it will probably end up being always equal because you are comparing the same object. Stupid user error....

@tdrake-cb

This comment has been minimized.

Copy link

commented Nov 13, 2017

I'm seeing this bug in 4.17.4

@matt-whitaker

This comment has been minimized.

Copy link

commented Jan 11, 2018

Is there any update on when this will be fixed?

@jdalton

This comment has been minimized.

Copy link
Member

commented Jan 11, 2018

This won't ship until v5.

Fixed in v4.17.5.

@htchaan

This comment has been minimized.

Copy link

commented Feb 7, 2018

@jdalton is there any reason why it can't be included in v4? its a bug, and its been over two years.

@jdalton

This comment has been minimized.

Copy link
Member

commented Feb 7, 2018

Looks like this fix made it into the patch bump 4.17.5 from a few days ago.

kalvinwang added a commit to CMSgov/qpp-measures-data that referenced this issue May 31, 2018

[QPPA-1607] Add tests and update ajv, ajv-keywords, eslint, mocha, lo…
…dash (#125)

- Add ajv-keywords so we can make use of `uniqueItemProperties: ['measureId']`
  - add the duplicate measure validation tests @samskeller suggested in #124 
- Update ajv 
  - migrate 2018 measures-schema from the draft-04 JSON schema spec to the draft-07 spec ([breaking changes](http://json-schema.org/draft-06/json-schema-release-notes.html#q-what-are-the-changes-between-draft-04-and-draft-06) were in 06)
- Update lodash (fixes _.isEqual bug: lodash/lodash#1758)
- Update mocha (`npm audit` showed a critical vulnerability in dependencies)
- Update eslint (`npm audit` showed a low severity vulnerability in dependencies)

Tests: added new tests, passes existing

Jira ticket: https://jira.cms.gov/browse/QPPA-1607 (adding the duplicate measure validation tests associated with 1607 led to the rest of these items)

Reviewer: @samskeller
@k-vekos

This comment has been minimized.

Copy link

commented Jun 12, 2018

@jdalton I'm getting false negatives even though I can look at the properties of each object and see that they're equal.

My example app: https://stackblitz.com/edit/angular-lodash-isequal?file=src%2Fapp%2Fhello.component.ts

If I replace line 25 let s1 = JSON.parse(JSON.stringify(this.schedule1)) as Schedule; with let s1 = this.schedule1; then it fixes the problem. I'm omitting functions though so I expect it to return that they're equal though.

@trlorenz

This comment has been minimized.

Copy link

commented Sep 10, 2018

Hi, @jdalton. Is this intended behavior (4.17.10)?

# coffeescript

MY.isEqual = (oldObj, newObj) ->
  _.isEqualWith oldObj, newObj, @_isEqualCustomizer

MY._isEqualCustomizer = (JUNK1, JUNK2, key) ->
  /^_IGNORE_/.test(key) || undefined

MY.isEqual({a: {_IGNORE_: true}}, {a: {_IGNORE_: false}})
# true

MY.isEqual({a: {_IGNORE_: true}}, {a: {}})
# false

MY.isEqual({a: {}}, {a: {_IGNORE_: true}})
# false

Obviously the intent here is to ignore keys beginning with '_IGNORE_', but unless the key exists in both objects, the node is never seen by the customizer.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
10 participants
You can’t perform that action at this time.