fix(node/assert): throw on deepStrictEqual({}, Object.create(null))
assert.deepStrictEqual now differentiates {} from Object.create(null)
This PR updates the object comparison logic to throw when comparing a plain object ({}) with an object created via Object.create(null), matching Node.js behavior.
Closes #27565
There are some tests failing because they expect the old behavior where deepStrictEqual({}, Object.create(null)) is true, like:
https://github.com/denoland/deno/blob/ff078dcfabfe916c63db800d2d91ca0dd77da5c7/tests/node_compat/test/parallel/test-sqlite-transactions.js#L32-L43
All the above assertions now fails because db.prepare('BEGIN').run() returns an object whose prototype is null __proto__: null, whereas the expected object { changes: 0, lastInsertRowid: 0 } has the default Object.prototype. Since assert.deepStrictEqual NOW checks both property values and the prototype chain, the difference in prototypes causes the assertion to fail.
I think that setting __proto__: null in the expected object is the best solution because it ensures that the object has no prototype and is an approach that is already being used in similar cases, like:
https://github.com/denoland/deno/blob/ff078dcfabfe916c63db800d2d91ca0dd77da5c7/tests/node_compat/test/parallel/test-sqlite-transactions.js#L44-L47
There are lots of assertions in the code base that rely on that old behavior, this patch will touch lots of files in the source tree.
Is that proposed change acceptable?
@kt3k @bartlomieju
@edilson258 Thanks for the PR. The maintainers will work on the fixes for the existing test cases (they should be passing as is). Please wait for a moment.
Note to self (and the team):
- [x] In
generateKeyPaircallback,publicKey.asymmetricKeyDetailsneeds to be have undefined prototype. #29576 - [x]
generateKeyPairSyncreturnspublicKeywhich needs to have undefined prototype. #29576 - [x]
StatementSync.prototype.run()needs to return object with undefined prototype. #29404
Thanks!