Simplify and enforce duplicate haste map errors

[mjesun]

This PR changes the way duplicated mocks and haste names are reported. The current way allows to have multiple times the same name, but emits a warning. After two years of having the warning in, I can tell you no one looks at it; so this diff starts enforcing them to be unique.

I also took the opportunity to standardize and simplify error messaging, since it was nearly impossible to read.

Before:

jest-haste-map: duplicate manual mock found:
  Module name: subdir/Blueberry
  Duplicate Mock path: /project/fruits2/__mocks__/subdir/Blueberry.js
This warning is caused by two manual mock files with the same file name.
Jest will use the mock file found in:
/project/fruits2/__mocks__/subdir/Blueberry.js
 Please delete one of the following two files:
 /project/fruits1/__mocks__/subdir/Blueberry.js
/project/fruits2/__mocks__/subdir/Blueberry.js

After:

jest-haste-map: duplicate manual mock found: subdir/Blueberry
  The following files share their name; please delete one of them:
    * <rootDir>/fruits1/__mocks__/subdir/Blueberry.js
    * <rootDir>/fruits2/__mocks__/subdir/Blueberry.js

Tests were adjusted accordingly to reflect the new logging mechanisms.

[SimenB]

Should this be considered a breaking change?

[mjesun]

Should this be considered a breaking change?

Probably, yes :)

[mjesun]

Should this be considered a breaking change?
Probably, yes :)

Let me clarify my "probably, yes"; although it's technically a breaking change, I do not expect anyone from being affected by this (no one has two http or fs mocks at the same time in their codebase). The reason why this is so frequent for us is due to Haste, which is (almost) not used in OSS.

So I think that we could still release as minor.

[rubennorte]

@mjesun #2070 might make this a problem for general users as well, not only for those using haste, which is why I think this should be a breaking change and probably delayed until we're close to release a major. But we can do now instead, is adding a new option in config.haste to throw an error instead of a warning in these cases (e.g. config.haste.throwOnDuplicates being false by default). We could remove the option in the next major if we want that to be the only behaviour.

[mjesun]

I will use throwOnModuleCollision to properly decide whether to break or not, so it's no longer a breaking change.

@rubennorte, you don't have to edit your comment to reflect what we just talked :D

[rubennorte]

That would also be a breaking change but given it's change on an undocumented option I think we can just asumme it.

[github-actions]

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.