jest-haste-map: throw when trying to get a duplicated module #3976
Conversation
types/HasteMap.js
Outdated
| }; | ||
| export type DuplicatesSet = {[filePath: string]: /* type */ number}; |
There was a problem hiding this comment.
mind moving this up, before it is first used?
|
Looks solid to me. Nice work. I'm slightly worried that this is going to incur a minor overhead for looking up a module, because of the many more added assertions, but we are paying the price for correctness. |
Totally, I'm concerned about the same. But it's a pretty simple hashmap access + function call, so it should be nicely optimized. I was considering doing the |
Codecov Report
@@ Coverage Diff @@
## master #3976 +/- ##
==========================================
+ Coverage 59.84% 59.93% +0.09%
==========================================
Files 196 196
Lines 6758 6787 +29
Branches 6 6
==========================================
+ Hits 4044 4068 +24
- Misses 2711 2716 +5
Partials 3 3
Continue to review full report at Codecov.
|
|
Whether this is a breaking change or not is to be discussed. I believe it's not really one, because having duplicate modules is broken anyway, as resolution algos would then try to do a Node.js-style resolve, that could pick up some random, unrelated module. At the same time, I don't want to cause hard crash on people's project especially if the duplicates are in their transitive dependencies. So I'd suggest considering this a breaking change. |
|
It shouldn't really matter for external folks, because haste is not really used outside of FB. Thanks for the fix! |
|
Haste is used for the Windows React Native hack, afaik. But normally they use "windows" platform extensions and there's no module conflicts, that would resolve incorrectly anyway. |
…3976) * jest-haste-map: throw when trying to get a duplicated module * fix lint * move type up as per comment
|
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
Right now, if a module is duplicated, we remove it from the module map, so that when we try to resolve it later, it doesn't return one or the other randomly, that would be incorrect, but instead nothing.
I realised this approach is better then returning a random module, but is still incorrect, because the callsite (resolution algorithm) could then try to resolve the module name as a Node.js package, and find some other module. This is just as random, and incorrect.
I believe the correct approach in case of duplicate modules for a single name is to prevent any further resolution by throwing an exception with sufficient metadata for the callsite, or the user, to make a decision. This changeset implements this correct behavior.
Test plan
yarn jest packages/jest-haste-map/src/__tests__/index.test.js