(preferences)(17.5.1)(fix) Fix preferences migration 17.5-specific deprecation test failures #58100
Conversation
This file contains 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
… migrated to the `core` scope, but will still work due to the 17.5.1-specific hotfix 17.5.1-specific hotfix: #58031.
|
Size Change: 0 B Total Size: 1.69 MB ℹ️ View Unchanged
|
fullofcaffeine
commented
Jan 23, 2024
| @@ -25,5 +25,12 @@ describe( 'Video block', () => { | |||
| dismissModal( screen.getByTestId( 'bottom-sheet' ) ); | |||
|
|
|||
| expect( screen.getByText( 'Invalid URL.' ) ).toBeVisible(); | |||
| // Expecations added due to a 17.5.1-specific hotifx: https://github.com/WordPress/gutenberg/pull/58031 | |||
There was a problem hiding this comment.
I started by ignoring per test, but the amount of failures in the mobile suites is way too high to add the expectations per test. If the approach below works fine, I'll remove this and use the same env file from other jest.config's.
fullofcaffeine
commented
Jan 23, 2024
| @@ -92,6 +92,10 @@ describe( 'actions', () => { | |||
| expect( registry.select( editPostStore ).getEditorMode() ).toEqual( | |||
| 'visual' | |||
| ); | |||
| // Expecation added due to a 17.5.1-specific hotifx: https://github.com/WordPress/gutenberg/pull/58031 | |||
There was a problem hiding this comment.
ditto the comment above.
fullofcaffeine
commented
Jan 23, 2024
| @@ -0,0 +1,23 @@ | |||
| const ignoredMessages = [ | |||
There was a problem hiding this comment.
This approach tries to ignore the deprecation messages globally. So far, it seems to work well. For now, I'm requiring it for the react native unit tests since I detected a lot of failures there but I will use it for others if I confirm it works well.
There was a problem hiding this comment.
Don't you think that it's better to ignore these locally. These messages shouldn't be triggered by Gutenberg by default and being able to catch up in unit tests seems like a good addition.
Obviously, if the unit test itself is still relying on deprecated APIs, it's fine for it to be using toHaveWarned...
There was a problem hiding this comment.
I agree on principle, but a lot of tests fail due to the unexpected deprecation messages; I think around 100 tests if we count the ~70 in the mobile suite, and possibly more. Adding the expectations to each test would require a significant amount of work. Maybe we should bite the bullet and cherry-pick the other settings scope migration PRs in this branch to fix the tests and perhaps revert the hotfix?
There was a problem hiding this comment.
I don't understand why that is the case in release/17.5 but not on trunk?
There was a problem hiding this comment.
release/17.5 is missing a few of the preference migration PRs that were added in the last few weeks, it seems.
There was a problem hiding this comment.
So you're saying that 17.5 didn't include the migration for a given key "a" but we're still calling the "deprecated" call for this same key and shiming it?
That sounds bad on multiple levels:
- It seems that this will cause the preference to not work at all because the editor is going to try to set
core/edit-postand readcore(because of the proxy and trigger a deprecation).
Do you know which migrations didn't make it into 17.5? We should just remove them from the "proxy"
There was a problem hiding this comment.
Yes, 17.5 didn't include all migrations; see the description for #58031, quoting:
One solution would be to cherry-pick the missing changesets. Still, I'm not sure if there could be other consequences (i.e if those changesets depend on other changesets that are supposed to be released with 17.6), so I've come up with this hotfix that should be merged only to the release/17.5 branch.
As for:
It seems that this will cause the preference to not work at all because the editor is going to try to set core/edit-post and read core (because of the proxy and trigger a deprecation).
That's what the 17.5-specific hotfix here aimed to fix: #58031. If it can't find on core, it will just try to get it from whatever scope was passed originally.
There was a problem hiding this comment.
Do you know which migrations didn't make it into 17.5? We should just remove them from the "proxy"
I don't, I can try to check today. Do we have a project or epic that encompasses all those migration PRs?
There was a problem hiding this comment.
Do we have a project or epic that encompasses all those migration PRs?
Nevermind, I can just get the list from the array in the proxy and build a list for release/17.5 using it. I'll get the list and remove the ones that have not been migrated in 17.5 from the proxy's list and will spin up a new 17.5-specific PR. Thanks for the insight!
There was a problem hiding this comment.
Related work continued in: #58145.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What / Why / How?
17.5-specific Follow-up to: #58031. That changeset was a time-sensitive hotfix for 17.5 with benign test failures, AFAICS. This PR aims to fix those tests in the 17.5 branches so that if any other PR is cherry-picked for a future patch release, people will not get confused by the failures.
It's important to note that once 17.6 is released, this will not be too relevant anymore, but will be a good way to document the changes in #58031.
The changes in #58031 make the
getproxy more resilient by falling back to the passed scope to get the preference if it's not found in thecorescope (where the preferences in thesettingsToMoveToCorewere migrated to between 17.5 andtrunk. Some changesets were not included in therelease/17.5branch, causing thegetcall for them to returnundefinedto the consumers and causing unexpected fatal bugs (BSODs/WSODs).On
trunknor this PR nor #58031 are needed because the it should be in a state that #58016 expects -- all of the preferences listed insettingsToMoveToCorehave indeed been moved over to thecorescope.Testing Instructions
All tests should pass.