Summary

jest-haste-map'sworker currently enforces (or tries to enforce) that all of its workloads use the samehasteImplModulePath.

This is problematic when multiple configurations, whosehasteImplModulePath may differ, share ajest-haste-map worker - in particular:

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

In these cases, whereworker.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 reusehasteImpl), 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 ofhasteImpl on the assumption that a given worker only sees one config. That caching doesn't really save any time though, becauserequire 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 wherejest-haste-map instances were allocatedMath.floor( (10-1) / 5 ) == 1 workers, and this change fixes it.