-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Fix diffing object contain readonly symbol key object #10414
Fix diffing object contain readonly symbol key object #10414
Conversation
should also overwrite symbol key descriptors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
All updated. |
@WeiAnAn I'm still getting an error with the original reported error /** @jest-environment jsdom */
test('boom', () => {
expect(document.createElement('div')).toBe(document.createElement('div'));
}); The error has changed, tho
Something about the replaced getter isn't working properly it seems |
@SimenB I found that it cause by we drop all nonenumerable property when copying. |
Sounds good! |
} else if (plugins.DOMElement.test(value)) { | ||
//@ts-expect-error skip casting to Node | ||
return value.cloneNode(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need a suggestion.
I don't think use @ts-expect-error
to ignore Property 'cloneNode' does not exist on type 'T'
is a good idea.
I met a problem to do DOM element tests, because the Add e2e to test is a way, but how to do in the unit test. |
@@ -42,6 +44,9 @@ export default function deepCyclicCopyReplaceable<T>( | |||
return deepCyclicCopyMap(value, cycles); | |||
} else if (isBuiltInObject(value)) { | |||
return value; | |||
} else if (plugins.DOMElement.test(value)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} else if (plugins.DOMElement.test(value)) { | |
} else if (typeof value.cloneNode === 'function') { |
maybe? not sure if it's better or not
@@ -42,6 +44,9 @@ export default function deepCyclicCopyReplaceable<T>( | |||
return deepCyclicCopyMap(value, cycles); | |||
} else if (isBuiltInObject(value)) { | |||
return value; | |||
} else if (plugins.DOMElement.test(value)) { | |||
//@ts-expect-error skip casting to Node | |||
return value.cloneNode(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return value.cloneNode(true); | |
return (((value as unknown) as Element).cloneNode(true) as unknown) as T; |
Can fix error with this, but a little bit ugly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment override is fine
As for the unit test, you can use a code comment: https://github.com/facebook/jest/blob/200adc053a40b1dae27d6304d24a605785c6b468/packages/pretty-format/src/__tests__/DOMElement.test.ts#L7 Just create a separate test file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great, thank you!
@SimenB, thank you too, you help me alot. |
In particular, this gets us Jest 26.4.1, which contains jestjs/jest#10414. This should fix an issue [1] we'd otherwise encounter very soon, where differences in a URL object encountered with `expect(...).toBe(...)` or `expect(...).toEqual(...)` would result in a very cryptic error message instead of a straightforward test failure with the desired explanation. This upgrade was pretty easy to do! I'm hoping fb23341 has increased the ease of staying up-to-date with Jest. Since we're going from a 22.x to 23.x of eslint-plugin-jest, we check the declared breaking changes at 23.0.0 [2]. The only one that concerns us is that part of the job of `jest/valid-describe` has been transferred to `jest/valid-title`, and `jest/valid-title` has been added to the `jest/recommended` config, which we take. The validation in question is silly, and unfortunately, we can't reasonably take all of `jest/valid-title` except that part, so, turn it all off. See also some prep work for this upgrade in a recent commit. [1] jestjs/jest#10408 [2] https://github.com/jest-community/eslint-plugin-jest/releases/tag/v23.0.0
In particular, this gets us Jest 26.4.1, which contains jestjs/jest#10414. This should fix an issue [1] we'd otherwise encounter very soon, where differences in a URL object encountered with `expect(...).toBe(...)` or `expect(...).toEqual(...)` would result in a very cryptic error message instead of a straightforward test failure with the desired explanation. This upgrade was pretty easy to do! I'm hoping fb23341 has increased the ease of staying up-to-date with Jest. Since we're going from a 22.x to 23.x of eslint-plugin-jest, we check the declared breaking changes at 23.0.0 [2]. The only one that concerns us is that part of the job of `jest/valid-describe` has been transferred to `jest/valid-title`, and `jest/valid-title` has been added to the `jest/recommended` config, which we take. The validation in question is silly, and unfortunately, we can't reasonably take all of `jest/valid-title` except that part, so, turn it all off. See also some prep work for this upgrade in a recent commit. [1] jestjs/jest#10408 [2] https://github.com/jest-community/eslint-plugin-jest/releases/tag/v23.0.0
In particular, this gets us Jest 26.4.1, which contains jestjs/jest#10414. This should fix an issue [1] we'd otherwise encounter very soon, where differences in a URL object encountered with `expect(...).toBe(...)` or `expect(...).toEqual(...)` would result in a very cryptic error message instead of a straightforward test failure with the desired explanation. This upgrade was pretty easy to do! I'm hoping fb23341 has increased the ease of staying up-to-date with Jest. Since we're going from a 22.x to 23.x of eslint-plugin-jest, we check the declared breaking changes at 23.0.0 [2]. The only one that concerns us is that part of the job of `jest/valid-describe` has been transferred to `jest/valid-title`, and `jest/valid-title` has been added to the `jest/recommended` config, which we take. The validation in question is silly, and unfortunately, we can't reasonably take all of `jest/valid-title` except that part, so, turn it all off. See also some prep work for this upgrade in a recent commit. [1] jestjs/jest#10408 [2] https://github.com/jest-community/eslint-plugin-jest/releases/tag/v23.0.0
In particular, this gets us Jest 26.4.1, which contains jestjs/jest#10414. This should fix an issue [1] we'd otherwise encounter very soon, where differences in a URL object encountered with `expect(...).toBe(...)` or `expect(...).toEqual(...)` would result in a very cryptic error message instead of a straightforward test failure with the desired explanation. This upgrade was pretty easy to do! I'm hoping fb23341 has increased the ease of staying up-to-date with Jest. Since we're going from a 22.x to 23.x of eslint-plugin-jest, we check the declared breaking changes at 23.0.0 [2]. The only one that concerns us is that part of the job of `jest/valid-describe` has been transferred to `jest/valid-title`, and `jest/valid-title` has been added to the `jest/recommended` config, which we take. The validation in question is silly, and unfortunately, we can't reasonably take all of `jest/valid-title` except that part, so, turn it all off. See also some prep work for this upgrade in a recent commit. [1] jestjs/jest#10408 [2] https://github.com/jest-community/eslint-plugin-jest/releases/tag/v23.0.0
In particular, this gets us Jest 26.4.1, which contains jestjs/jest#10414. This should fix an issue [1] we'd otherwise encounter very soon, where differences in a URL object encountered with `expect(...).toBe(...)` or `expect(...).toEqual(...)` would result in a very cryptic error message instead of a straightforward test failure with the desired explanation. This upgrade was pretty easy to do! I'm hoping fb23341 has increased the ease of staying up-to-date with Jest. Since we're going from a 22.x to 23.x of eslint-plugin-jest, we check the declared breaking changes at 23.0.0 [2]. The only one that concerns us is that part of the job of `jest/valid-describe` has been transferred to `jest/valid-title`, and `jest/valid-title` has been added to the `jest/recommended` config, which we take. The validation in question is silly, and unfortunately, we can't reasonably take all of `jest/valid-title` except that part, so, turn it all off. See also some prep work for this upgrade in a recent commit. [1] jestjs/jest#10408 [2] https://github.com/jest-community/eslint-plugin-jest/releases/tag/v23.0.0
jest update motivated by jestjs/jest#10414 -- unhelpful message instead of object diff in failed tests (eg when using immer)
… failed tests (eg when using immer)
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
Fix #14018.
The reason is forget to copy and overwrite symbol key object descriptor in
deepCyclicCopyObject
.I refactor
deepCyclicCopyObject
to use same logic in both string key and symbol key.Test plan
Add
symbol key object
test andreadonly property
test indeepCyclicCopyReplaceable.test.ts
.Add
object contain readonly symbol key object
test inprintDiffOrStringify.test
.