Summary

jest-haste-map's worker currently enforces (or tries to enforce) that all of its workloads use the same hasteImplModulePath.

This is problematic when multiple configurations, whose hasteImplModulePath may differ, share a jest-haste-map worker - in particular:

• when --runInBand or --maxWorkers=1
• where there are sufficient configs that Math.floor(maxWorkers / configs.length) == 1,
• During watch mode, when all jest-file-map processing is in-band.

In these cases, where worker.js is loaded as an ordinary module by the host process, there are two bugs:

• If one project uses Haste and another does not, hasteImpl will be set by the first config and incorrectly silently reused by the second config (because we don't trigger the error condition, but do reuse hasteImpl), potentially causing spurious collision errors.
• If two configs try to use non-null, different haste impls, which should be valid, the worker will throw.

The point of this check seems to be to allow caching of hasteImpl on the assumption that a given worker only sees one config. That caching doesn't really save any time though, because require calls are already backed by Node's own module cache.

So we simplify the worker, fix the bugs, and incur no observable performance penalty by just removing the check.

Test plan

Made this modification locally to Jest at Meta, where we currently have 5 projects including 2 different haste impls. We observed the bug on 10 core machines where jest-haste-map instances were allocated Math.floor( (10-1) / 5 ) == 1 workers, and this change fixes it.