fix(js/useSortedKeys): don't compare named properties with nameless ones #6551
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.
Summary
Fix #6536
The bug was not related to the implementation of the String collator that we fixed in #5775.
Instead, this is coming from the implementation of
useSOrtedKeysitself.Actually I had suspicions about the current implementation of the rule. Notably about returning
EqualinObjectMmeber::cmpwhen we didn't manage to retrieve one of the name.The bug is actually coming from exactly this.
The property without name is the code provided in #6536 is the object spread.
Reading the rule description, I noticed that the documentation asserts that a chunk/group of property should be sorted until a spread / bogus node / property without name is found.
I changed the implementation to match exactly this.
We no longer push an object spread or any property without name or an unreachable name.
This solves the issue.
json/useSortedKeysanduseSOrtedAttributeshave also a similar issue. However, this should be hard to trigger because we need bogus nodes. I will fix these rules in future PRs.Also, I took the opportunity of switching to a stable sort in order to keep the relative order between two properties. This is useful when we sort an object with a getter and a setter with an identical name: we guarantee that their relative order doesn't change.
I wonder if we should not encode a total order between a getter and a setter: the action could then always sort the getter before the setter. This could overlap with useAdjacentGetterSetter's action. However, this looks like an expected behavior for
useSortedKeys?I was also able to remove a
FIXME:)Test Plan