You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
toMatchObject produces an unreadable diff when the actual value has properties that live on its prototype chain instead of as own enumerable properties - for example, DOM elements, where tagName, id, etc. are accessor properties on Element.prototype, not own properties on the instance.
Root cause:getObjectSubset (in packages/expect/src/jest-utils.ts) built the "actual" side of the diff by iterating getObjectKeys(object), which only returns own enumerable keys. For a DOM element this returns an empty array, so the subset-building loop never ran and the function fell through to returning the raw object — which the pretty-print layer then serialized as <div><img /></div> instead of a plain-object diff.
Fix: iterate getObjectKeys(subset) instead, and check presence with key in object, which walks the prototype chain. subset is always the object literal the caller wrote, so its keys are reliable regardless of what actual is. The existing "N properties omitted from actual" counting logic is unchanged — it still iterates object's own keys separately.
Known related gap: the one-line summary message ("expected {...} to match object {...}") stringifies the actual value via a separate code path (utils.getMessage) not touched by this fix, so it may still omit inherited properties there even though the diff body is now correct. Flagging rather than silently leaving it out of scope — happy to follow up separately if useful.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
Ideally, include a test that fails without this PR but passes with it.
Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.
Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.
Tests
Run the tests with pnpm test:ci.
Ran the full @vitest/test-unit suite (640 files, 7600 tests, all passing, no type errors) and pnpm test:ci. The only failure in test:ci was a pre-existing, unrelated snapshot mismatch in test-coverage (5.0.0-rc.1 vs 5.0.0-beta.7 version string), unrelated to this change.
Documentation
If you introduce new functionality, document it. You can run documentation with pnpm run docs command.
N/A — this is a bugfix to existing behavior, no new functionality introduced.
Changesets
Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.
I used Claude as an assistant while investigating and tracing the root cause through the codebase; the diagnosis, fix, and test above are ones I understand and can walk through.
Checked the failing CI jobs — all 6 e2e matrix failures (ubuntu/macos/windows, node 22/24/26, vite@7) come from the same 2 tests in test/e2e/test/artifacts.test.ts (reporters > verbose non-tty and reporters > default), and they're unrelated to this change:
- RUN v<version> <root>
+ RUN v<version>-rc.1 <root>
The CI environment is running a -rc.1 prerelease build, and the snapshot's version-normalization logic isn't stripping the -rc.1 suffix before comparison. Nothing here touches toMatchObject, getObjectSubset, or packages/expect — this would fail on main too. Locally, all @vitest/expect-related tests pass (@vitest/test-unit: 640 files, 7600 tests, 0 failures), and the Diff/Lint/unit-test-matrix CI jobs (10/11) all passed cleanly on this PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
toMatchObjectproduces an unreadable diff when the actual value has properties that live on its prototype chain instead of as own enumerable properties - for example, DOM elements, wheretagName,id, etc. are accessor properties onElement.prototype, not own properties on the instance.Root cause:
getObjectSubset(inpackages/expect/src/jest-utils.ts) built the "actual" side of the diff by iteratinggetObjectKeys(object), which only returns own enumerable keys. For a DOM element this returns an empty array, so the subset-building loop never ran and the function fell through to returning the raw object — which the pretty-print layer then serialized as<div><img /></div>instead of a plain-object diff.Fix: iterate
getObjectKeys(subset)instead, and check presence withkey in object, which walks the prototype chain.subsetis always the object literal the caller wrote, so its keys are reliable regardless of whatactualis. The existing "N properties omitted from actual" counting logic is unchanged — it still iteratesobject's own keys separately.Known related gap: the one-line summary message (
"expected {...} to match object {...}") stringifies the actual value via a separate code path (utils.getMessage) not touched by this fix, so it may still omit inherited properties there even though the diff body is now correct. Flagging rather than silently leaving it out of scope — happy to follow up separately if useful.Resolves #6939
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Ran the full
@vitest/test-unitsuite (640 files, 7600 tests, all passing, no type errors) andpnpm test:ci. The only failure intest:ciwas a pre-existing, unrelated snapshot mismatch intest-coverage(5.0.0-rc.1vs5.0.0-beta.7version string), unrelated to this change.Documentation
pnpm run docscommand.N/A — this is a bugfix to existing behavior, no new functionality introduced.
Changesets
feat:,fix:,perf:,docs:, orchore:.I used Claude as an assistant while investigating and tracing the root cause through the codebase; the diagnosis, fix, and test above are ones I understand and can walk through.