| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
There are a lot of unrelated changes, making this hard to review. Consider removing those (maybe a problem with the configuration of your text editor?), and run the linters (NODE=node make test-doc -j and make lint-js).
Sorry, something went wrong.
| - `expected` {any} | ||
| - `message` {string|Error} | ||
|
|
||
| Tests strict equality between the `actual` and `expected` parameters. |
There was a problem hiding this comment.
That's hardly what's happening, is it? At least I find the wording very confusing (I would expect the same behavior as strictEqual with the current wording), we should explain in more details what's happening here, what's being compared: is it only own properties? is the prototype important?
Sorry, something went wrong.
| - `actual` {any} | ||
| - `expected` {any} |
There was a problem hiding this comment.
Is it actually any? What happens if we pass a primitive?
Sorry, something went wrong.
There was a problem hiding this comment.
It's any because it compares the values (and the keys), which could be primitives. I'll add a couple of tests for primitives too.
Sorry, something went wrong.
|
@nodejs/assert |
Sorry, something went wrong.
There was a problem hiding this comment.
Feel free to suggest more types to be tested.
Should't this fall back on assert.deepEqual and assert.deepStrictEqual respectively when dealing with anything but simple objects?
If I pass two different KeyObject or CryptoKey instances to matchObject, despite them being different cryptographic keys this doens't throw.
If it falled back on on assert.deepEqual and assert.deepStrictEqual then handling of those respective objects would be handled (#50897).
lib/internal/util/comparisons.js already has these already in
Sorry, something went wrong.
|
Based on the docs I find it very confusing to discern between this and assert.deep(Strict)Equal. "Matching" suggests (to me at least) that the "expected" argument might be an object with more properties than "actual" but that's not what's documented nor implemented. |
Sorry, something went wrong.
Should be handled now |
Sorry, something went wrong.
|
please remove merge commit. changes generally LGTM, I think this is a great addition to node:assert |
Sorry, something went wrong.
|
@nodejs/assert How sure are we that we want to add this? If it lands, should it be added as experimental for a while to give us the option to change it as we see fit for a while or even remove it entirely without waiting for a major release? |
Sorry, something went wrong.
There was a problem hiding this comment.
I'm still not convinced that this is sufficiently different from deepEqual and deepStrictEqual to warrant a new API. At the absolute least the documentation does not provide enough information for someone to be able to decide which to use
Sorry, something went wrong.
There was a problem hiding this comment.
@jasnell If the expected object has fewer properties than the actual object, deepEqual will throw an error based on your example. On the other hand, matchObject will compare the existing properties and values in the expected object, allowing for a partial comparison.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah I get that, I just do not think there's enough justification for a new api. A new option to the existing method could do the same.
Sorry, something went wrong.
There was a problem hiding this comment.
There was some conversation in the original issue about whether it should be:
here @synapse decided to go with option 1, lacking a clear consensus on which option made the most sense
Sorry, something went wrong.
There was a problem hiding this comment.
I'm still not convinced that this is sufficiently different from deepEqual and deepStrictEqual to warrant a new API. At the absolute least the documentation does not provide enough information for someone to be able to decide which to use
I agree. I would love to see node:assert have a match function equivalent to https://github.com/tapjs/tapjs/blob/8f2baa7eb5e1f4cd0fcf8b60da4fb4e41ea680f1/docs/src/content/docs/api/asserts/index.md?plain=1#L318-L338
But the proposal here seems like a less consistent deepStrictEqual.
Sorry, something went wrong.
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
| present in the `actual` parameter with equivalent values, permitting type coercion | ||
| where necessary. |
There was a problem hiding this comment.
these seem flipped - the strict variant should not allow type coercion, and the loose variant should permit it.
Sorry, something went wrong.
|
This PR can be closed as work on the linked issue is being done elsewhere. |
Sorry, something went wrong.
Where is that work happening? |
Sorry, something went wrong.
|
Sorry, something went wrong.
|
This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open. |
Sorry, something went wrong.
Sorry, something went wrong.
Thank you. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
fixes #50399
What is this PR doing:
The compareBranch (used by matchObject) works as follows: