-
-
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 recovery of haste collisions #7329
Conversation
8712cd5
to
16b094d
Compare
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 remember we were using an object so that it can be serialised/deserialised from the cache very fast. A Map would not get serialised properly I think. Can you confirm what's the status for this?
The cache system of Regarding performance, I wouldn't worry here since the number of duplicates in the haste map should be rather small |
Answered the concern that @jeanlauliac had
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.
Cool, then that sounds good to me 🎉
16b094d
to
e2f21d4
Compare
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
jest-haste-map
had a bug when recovering from a haste name collision: it was using thetype
from the deleted file instead of the type from the remaining file in the haste map.This PR fixes this issue, while it also changes the internal data structure that holds the duplicated modules.
I've split the PR into two commits: the first one only fixes the issue and the second one converts the
duplicates
structure into aMap
. We can discard the second commit if needed.I've marked the change as a breaking change since the duplicated modules are part of the public API of
jest-haste-map
(although it should be very rare for a user to rely on this).Test plan
I've created a new unit test that ensures the correct behaviour (that test would fail currently in master).